Hi Rick,

How are things? I hope all is well.

We encountered trouble uploading large PDF files (70MB in this case) to a WWWC app. On my local box, I can make this work by bumping up the IIS maxAllowedContentLength setting. But on the target server, the upload then fails with this WWWC error page:

An error occurred during COM object invokation.

StringToBSTR Failed on Request. Err code = 80070008: Not enough storage is available to process this command.

Any ideas what the issue is and how to resolve it? Thanks! -rp

Hey Randy,

Long time no see here 😃

That seems like an out of memory error. Data comes in in binary and is converted to string to pass to FoxPro and that's what's failing. What happens there is:

• Capture original 70mb as bytes
• Convert those to a Unicode COM string (which doubles up - 140mb)

this means that 70mb transfer likely is around 280mb of memory usage. Yikes! If you have multiples of these going at once (because it's slow perhaps?) I can see easily running out of available memory.

Since you're seeing this specific error I presume you're using the ISAPI extension. The .NET Manager - and especially the newest version in 7.13 - are likely to handle this better as it's going through higher level .NET COM APIs. 7.13 also doesn't convert to string but captures the raw binary data and directly transfers that data to the COM objects without converting to string (requires matches set of DLL and FoxPro framework as there is a new binary input method ProcessHitBinary()).

+++ Rick ---

Thanks for the reply, Rick. In the past we couldn't readily switch to the .NET Manager, because you said it was limited to single-virtual applications (or something like that).

Is that still the case? The apps in question for us respond on 2 or more virtuals, and with multiple scriptmaps.

Yes - .NET application's can't span multiple IIS Applications - never could and never will. However, you can use a root site plus virtuals (not Applications) and that does work as they are essentially running in a single .NET AppDomain but that also changes the semantics of the 'root' application which figures out where ~/ points to etc.

IAC, the semantics of this haven't changed.

In wc.dll there's likely no relief for the large file issue - it's a matter of running out of heap space for the memory allocation.

+++ Rick ---