Limited ASPNET system resources?

[Roger]

Are there some system resources which the ASPNET user account gets less
of, by default?

I'm running into a problem with a web service that I'm working on. I
have a 3rd-party program which the web service interacts with, and I
have several documents associated with this program. Some of these
documents are small, and some of the documents are extremely large.

The 3rd party program opens all of these documents just fine when
running under my user account. But opening the larger documents causes
the program to crash when it's run under the ASPNET user account (from
the web service). Thus, I'm inclined to think that there's some
limited system resource that the ASPNET account doesn't have as much of
as a default user account.

Can anyone offer some suggestions of what resources might be the
culprit, and how this problem might be addressed? Thanks.

- Roger

[Trevor Pinkney]

Does the security on the server grant the appropriate permissions to view
the large documents with the ASPNET account? I assume it does since it sounds
like the smaller documents open fine.

I don't know why one account would be restricted resources. Especially the
ASPNET account since its important to web servers.

Do you get a certain error message when the program crashes?

-Trevor

Are there some system resources which the ASPNET user account gets
less of, by default?

I'm running into a problem with a web service that I'm working on. I
have a 3rd-party program which the web service interacts with, and I
have several documents associated with this program. Some of these
documents are small, and some of the documents are extremely large.

The 3rd party program opens all of these documents just fine when
running under my user account. But opening the larger documents
causes the program to crash when it's run under the ASPNET user
account (from the web service). Thus, I'm inclined to think that
there's some limited system resource that the ASPNET account doesn't
have as much of as a default user account.

Can anyone offer some suggestions of what resources might be the
culprit, and how this problem might be addressed? Thanks.

- Roger

[Roger]

Yes, the ASPNET account has sufficient permissions to access the
documents. If I open one of the large documents with my own account
and then remove enough data then it will open fine from the web
service.

Unfortunately, the crash is just a typical access violation
(0xc0000005). I thought that perhaps the program was trying to
allocate some system resources and wasn't checking the returned handle
before trying to use them. But as to what that resource might be, I
have no idea.... and hence, my original question :)

[Roger]

Some more information which might be helpful:

Looking at the disassembly of the program that is crashing, the crash
appears to occur during an attempted call to GetClientRect.

Would the ASPNET user account have trouble allocating large numbers of
window handles, perhaps?

[Trevor Pinkney]

Hmmm... notify the 3rd party and see what they think... They should be showing
a friendly error message if something like this happens. ie. maybe their
software attempts to write a file behind the scenes to a temp folder.

Yes, the ASPNET account has sufficient permissions to access the
documents. If I open one of the large documents with my own account
and then remove enough data then it will open fine from the web
service.

Unfortunately, the crash is just a typical access violation
(0xc0000005). I thought that perhaps the program was trying to
allocate some system resources and wasn't checking the returned handle
before trying to use them. But as to what that resource might be, I
have no idea.... and hence, my original question :)

[Trevor Pinkney]

Googled the function name - I assume this is why you are referring to handles...

http://msdn.microsoft.com/library/de...clientrect.asp

"GetClientRect function retrieves the coordinates of a window's client area"

Maybe you need special permissions to access/view the client screen????
It is weird the 3rd party component needs access to the screen. ie. Is
it meant to be hosted on a web server?

-Trevor

Some more information which might be helpful:

Looking at the disassembly of the program that is crashing, the crash
appears to occur during an attempted call to GetClientRect.

Would the ASPNET user account have trouble allocating large numbers of
window handles, perhaps?

[Roger]

Thanks for your suggestions. I finally found a solution to the
problem!

The 3rd-party application uses a large number of user objects, even
when it's running under a web service (it's a poorly designed app -
registers WAY too many windows). It was failing in the ASPNET user
account because non-interactive desktops are given a smaller desktop
heap.

Increasing the amount of desktop heap available to non-interactive
desktops seems to have fixed the problem. The default, 512k, was just
too small for this app... I upped it to 1024k.

The registry key was found here:
http://support.microsoft.com/default.aspx?kbid=126962