Limited ASPNET system resources?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Roger - 21 Feb 2005 20:08 GMT

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

Reply to this Message

Trevor Pinkney - 21 Feb 2005 20:59 GMT

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?
[quoted text clipped - 15 lines]
>
> - Roger

Reply to this Message

Roger - 21 Feb 2005 21:16 GMT

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 :)

Reply to this Message

Trevor Pinkney - 21 Feb 2005 21:39 GMT

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
[quoted text clipped - 6 lines]
> before trying to use them. But as to what that resource might be, I
> have no idea.... and hence, my original question :)

Reply to this Message

Roger - 21 Feb 2005 21:38 GMT

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?

Reply to this Message

Trevor Pinkney - 21 Feb 2005 22:04 GMT

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/win
dowsuserinterface/windowing/windows/windowreference/windowfunctions/getclientrec
t.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:
>
[quoted text clipped - 3 lines]
> Would the ASPNET user account have trouble allocating large numbers of
> window handles, perhaps?

Reply to this Message

Roger - 21 Feb 2005 23:56 GMT

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

Reply to this Message

Limited ASPNET system resources?

Free Magazines