Hi Axel, Sounds like the imfamous missing ASP.NET account issue.
>From microsoft.public.dotnet.framework.performance: Adam, In response to your questions: 1. Yes, we have acknowledged that this is a know bug. 2. We have not published a KB article on this issue. 3. The workaround is to either create a disabled local ASPNET account or a domain account (though we cannot guarentee that this is a secure solution). Note that if you add the local account manually and then at some later date attempt to install ASP.NET the installation will break (because the ASPNET user will already exist). You will need to remove the ASPNET account before doing the installation. 4. This bug is fixed in SP2 of the .NET Framework. SP2 is expected to ship by September. Gregor Noriskin CLR Performance Program Manager Microsoft This posting is provided "AS IS" with no warranties, and confers no rights. "Adam Shaked Gish" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > Hello > > I have a native application that uses .NET Assembles via Com Interop. > I have noticed that when the application starts it stalls just about > when the .NET framework DLLs start loading. It can get stuck for > several minutes. > In order to understand what was going wrong I used the Depends.exe > profiling capabilities and found that the My process was getting stuck > on one of the following two calls (probably the OpenProcessToken, > assuming that the message is printed after the call is completed): > > GetProcAddress(0x77DB0000 [ADVAPI32.DLL], "AllocateAndInitializeSid") > called from "MSCORWKS.DLL" at address 0x791C8F38 and returned > 0x77DB9D7D. > GetProcAddress(0x77DB0000 [ADVAPI32.DLL], "OpenProcessToken") called > from "MSCORWKS.DLL" at address 0x791C9162 and returned 0x77DB7C9E. > > I have searched the web for this problem and came upon a workaround > that suggested that I create a local user named ASPNET on those > machines where we experience the problem. > > I have done so, and it works! The application does not stop for this > call anymore and loads more or less at the same speed we had before > introducing .NET components into it. > > All this is very nice but when the development stage is done we will > be installing this application for our clients that have very strict > IT departments... I can just imagine explaining to them that my > desktop application installation requires adding a user named ASPNET > on their client machines... > > Before using one of my precious "Official Support Calls" I would like > to know: > > 1. Has Microsoft ever acknowledged this being a problem? > 2. Is there any information available about the status of this issue? > 3. Is there a more reasonable way to handle this issue? > 4. Will Microsoft provide some fix? When? > > I would even feel better if Microsoft installed this user as part of > their redistribution package. I just do not want to do this without > knowing that this is the correct thing to do. > > Thank you > > Adam Shaked Gish ----- Original Message ----- From: "Axel Heitland" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 24, 2002 6:36 AM Subject: [DOTNET] Very very slow startup of dotneet applications All .net applications take up to 40 sec to start up. Our surrounding is a large corporate network and non-.net-apps's behave quite nice. We're running XP against a Win2K active directory environment. It seems that .net apps perform some spoofing on the network and I'd be corious to know what this might be. I tried to turn off security, log-on as local user et.al. - without any success. Plugging of the network cable is the only solution - when I do this the apps are starting up smoothely within millseconds. The minimal app is a console application doing nothing... Using netmon I found a "bad opcode" reply from our domain controller during a LsaRpcPolicy command. That looks like a problem within our network, but I need to convince our sys-admins... Any pointers? My regards Axel You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
