Limited ASPNET system resources?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Roger

    Limited ASPNET system resources?

    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

    #2
    Re: Limited ASPNET system resources?

    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
    [color=blue]
    > 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
    >[/color]



    Comment

    • Roger

      #3
      Re: Limited ASPNET system resources?

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

      Comment

      • Roger

        #4
        Re: Limited ASPNET system resources?

        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?

        Comment

        • Trevor Pinkney

          #5
          Re: Limited ASPNET system resources?

          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.


          [color=blue]
          > 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 :)
          >[/color]



          Comment

          • Trevor Pinkney

            #6
            Re: Limited ASPNET system resources?

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



            "GetClientR ect 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


            [color=blue]
            > 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?
            >[/color]





            Comment

            • Roger

              #7
              Re: Limited ASPNET system resources?

              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:


              Comment

              Working...