Upload file from 32Bit Machine fails to IIS 7

Question

I am developing a Windows application that uploads a file to a webserver, IIS. My code is working just fine when I run the app on a 64Bit Machine. Upload to the IIS is working. But when I run it on a 32Bit machine, the upload is not working.

I think it has something to do with IIS. But I don´t know what it could be. Does someone has experienced same issues?

UPDATE: This has nothing to with the server side. I tested several endpoints, but nothing worked.

This must be related to my upload code. This code is working from 64Bit Apps but not on 32Bit:

try
        {
            System.Net.Http.HttpClient hc = new System.Net.Http.HttpClient();
            hc.DefaultRequestHeaders.TryAddWithoutValidation("Accept", "text/html,application/xhtml+xml,application/xml");
            hc.DefaultRequestHeaders.TryAddWithoutValidation("Accept-Encoding", "gzip, deflate");
            hc.DefaultRequestHeaders.TryAddWithoutValidation("User-Agent", "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0");
            hc.DefaultRequestHeaders.TryAddWithoutValidation("Accept-Charset", "ISO-8859-1");

            using (VirtualStream ms = new VirtualStream() { Size = UploadSize })
            {
                StreamContent content = new StreamContent(ms, BufferSize);

                // time for the calculation of the total average throughput
                var overallStart = DateTime.Now;

                var start = DateTime.Now;

                var responseTask = hc.PostAsync(URL, content);

                while (!responseTask.IsCompleted)
                {
                    // Check the Exit and Abort Constraints
                    if ((DateTime.Now - overallStart).TotalMilliseconds > MaxTestLength || _cancelationRequested)
                    {
                        System.Diagnostics.Debug.WriteLine("Bytes sent " + bytesSent);
                        hc.CancelPendingRequests();
                        IsRunning = false;
                        return;
                    }

                    try
                    {
                        bytesSent = ms.Position - bytesOfCalibrationPhase;
                    }
                    catch (Exception)
                    {
                        // The Upload is an async process which dispses the underlying stream when the upload finishes
                        // In some cases this could lead to ObjectDiposed Exceptions when accessing the current stream position
                        // If it is the case, the upload has finished....
                        break;
                    }


                }

BytesSent is always "0" on 32Bit machines...Why is that?

Answer 1

It seems to me that the loop you have is there for three reasons:

1) You want to cancel the upload if cancellation is requested

2) You want to cancel the upload if there is a timeout

3) you want to know the progress of the upload

I suggest that you remove the loop completely, and achieve these tree goals in a different way. Here is how you can do this:

For (1), use the other overload of the PostAsync method that has a CancellationToken parameter. This allows you to provide a token that you can use from somewhere else to cancel the upload operation.

For (2), you can use the CancellationTokenSource (that you used to create the CancellationToken), to request that the upload operation be canceled after some time (if the task was not already completed). See the CancelAfter method.

Here is some code sample for (1) and (2):

Put the following two lines in some place (probably as fields) so that these variables are available from both your upload code and the code that might wish to cancel the upload:

CancellationTokenSource cancellation_token_source = new CancellationTokenSource();
CancellationToken cancellation_token = cancellation_token_source.Token;

The following line of code will setup automatic cancellation after 10 seconds:

cancellation_token_source.CancelAfter(TimeSpan.FromSeconds(10));

In the following line, we pass the cancellation_token to the PostAsync method:

var responseTask = hc.PostAsync(URL, content, cancellation_token);

I noticed you were waiting for responseTask.IsCompleted to become true. This means that you don't want your method to return until the upload is complete. In this case, use the following to wait for the upload to complete.

responseTask.Wait();

In case you want to convert your method to become asynchronous, mark your method as async, and instead use the following:

await responseTask;

You can use the following to cancel the upload:

cancellation_token_source.Cancel();

For (3), first look at the answers in this question.

If this does not work for you, I have the following suggestion:

You can create a decorator for the Stream class, that informs you when the stream was read, like this (please note the Read method):

public class ReadNotifierStreamWrapper : Stream
{
    private readonly Stream m_Stream;

    private readonly Action<int> m_ReadNotifier;

    public ReadNotifierStreamWrapper(Stream stream, Action<int> read_notifier)
    {
        m_Stream = stream;
        m_ReadNotifier = read_notifier;
    }

    public override void Flush()
    {
        m_Stream.Flush();
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
        return m_Stream.Seek(offset, origin);
    }

    public override void SetLength(long value)
    {
        m_Stream.SetLength(value);
    }

    public override int Read(byte[] buffer, int offset, int count)
    {
        var bytes_read = m_Stream.Read(buffer, offset, count);

        m_ReadNotifier(bytes_read);

        return bytes_read;
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        m_Stream.Write(buffer, offset, count);
    }

    public override bool CanRead
    {
        get { return m_Stream.CanRead; }
    }

    public override bool CanSeek
    {
        get { return m_Stream.CanSeek; }
    }

    public override bool CanWrite
    {
        get { return m_Stream.CanWrite; }
    }

    public override long Length
    {
        get { return m_Stream.Length; }
    }

    public override long Position
    {
        get { return m_Stream.Position; }
        set { m_Stream.Position = value; }
    }
}

And then you can use it to wrap your ms stream like this:

int total_bytes = 0;

var stream_wrapper = new ReadNotifierStreamWrapper(ms , bytes =>
{
    total_bytes += bytes;

    Debug.WriteLine("Bytes sent " + total_bytes);
});

HttpContent content = new StreamContent(stream_wrapper); //Here we are creating the StreamContent from stream_wrapper instead of ms

This way you will get a notification when the stream is being read. And you will know how much bytes were read.

Please note that you might need to work more on the ReadNotifierStreamWrapper class to make it better. For example, maybe the HttpClient decides for some reason that it wants to seek the stream via the Seek method. You might need to take that into account. Although, I don't think that HttpClient will do this since it needs to read the whole file to upload it all, it does not make sense to skip parts of the file. You can put some breakpoints on the Seek method of ReadNotifierStreamWrapper to see if it will get called.

Answer 2

The exception you get;

EventSourceException: No Free Buffers available from the operating system

is caused by the Debug.WriteLine, which uses ETW (Event Tracing for Windows). ETW is a Windows kernel-level tracing facility that relies on a number of buffers to cache data before writing it to disk. ETW uses the buffer size and the size of physical memory to calculate the maximum number of buffers allocated for the event tracing session's buffer pool. So, if your application is 64-bit ETW will allocate more buffers due to there being more addressable memory available.

The reason you are hitting the limit is that you are writing debugging events faster than ETW can process the buffers.

I believe it is possible to increase the maximum number of buffers using registry entries, but this will increase memory consumption and you have the potential to hit the limit again with bigger files, slower connection, etc. So your best bet is to either sleep the thread on each loop to write tracing events at a lower rate or replace the Debug.WriteLine with some other form of logging.