error: The application failed to initialize properly (0xc0000005). Click on OK to terminate the application.

Question

Hi.

 

I am trying to use the instrumented profiler and am getting this error when running the instrumented binary with the profiler active from the commandline.  Any ideas?

 

Didier

Answer 1

I can't really help you without knowing more about the application that you are running. Is this a managed or a native application? Was the binary signed before instrumentation (signing is destroyed during instrumentation and you will have to re-sign after)? Any more info that you could provide would be helpful in diagnosing this issue.

 

Thanks,

Ian

Answer 2

Hi Ian,

 

Thank you for responding.  The application is not managed.  It's a highly anticipated windows game to be released in a few months.  I looked into the signing problem and we aren't signing the binary in a post-build step.  It happens on the build server during the installer creation step.

 

I also thought it might have something to do with my antivirus program detecting some process injection, but I really have no idea how the profiler attaches itself to the instrumented code at runtime.

 

I tried using the commandline to instrument the binary and that works fine.  When I run the game it runs fine as long as the profiler isn't enabled.  As soon as I enable the profiler, it will crash with this error.

 

Didier

Answer 3

Sounds like you must be running some application to hook that process in a bad way. Some possible culprits could be AppVerifier or several Anti-Virus programs. To get the profiler up and running I would prune out all the running services and process that I could and find out when you can get the profiler running add them back in until you find the program that is causing the issue.

 

~Ian

 

Answer 4

Do you know how the vs perf monitor hooks the intrumented application.  It didn't seem to have a problem with my test project that had nothing in it but a main function.  I tried uninstalling my antivirus (eTrust), but that didn't help.  I'm also not running the app verifier.

 

Didier

Answer 5

Do you have a debugger where you could attach at the crash point and see what the stack is at the exception? Knowing that would help in trying to narrow this down. Also, as a side note is the file VSPerf80.dll in the path that you are working in?

 

Thanks,

Ian

 

Answer 6

It looks like the problem was that the reserved stack size was set for 2MB.  I changed this back to the default and it is working.  Is this a bug in the profiler?  I am curious why this is happening.

 

Didier

Answer 7

So that didn't completely solve the problem.  That makes the debug build work for profiling, but the release version still has the same problem with the crash on initialization.

 

Answer 8

I'm starting to think this has something to do with our custom memory allocator.  We have overridden the global operator new/delete.  Our debug allocator puts a header/footer around the allocation, however the release version does not.  Is the profiler assuming that allocations come from the CRT heap?

 

Didier

Answer 9

Now I'm thinking this is a problem caused by the exception handler.  We are using SetUnhandledExceptionFilter, perhaps improperly.  I'm still looking into it.

Answer 10

 

After adding the symbol server, i was able to track it down to the fact that the lib include order matters.  Here's the article that I read:

 

http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2005-02/0629.html

 

I was getting the following callstack until I moved VSPerf80.dll to a delay load:

 

  ntdll.dll!_RtlpWaitForCriticalSection@4()  + 0x5b bytes 
  ntdll.dll!_RtlEnterCriticalSection@4()  + 0x46 bytes 
  rpcrt4.dll!PerformRpcInitialization()  + 0x24ac0 bytes 
  rpcrt4.dll!_RpcStringBindingComposeW@24()  + 0x20df9 bytes 
  advapi32.dll!_EVENTLOG_HANDLE_W_bind@4()  + 0x29 bytes 
  rpcrt4.dll!GenericHandleMgr()  + 0x85 bytes 
  rpcrt4.dll!ExplicitBindHandleMgr()  + 0x5d0c bytes 
  rpcrt4.dll!_NdrClientCall2()  + 0xbd bytes 
  advapi32.dll!_ElfrRegisterEventSourceW@24()  + 0x1b bytes 
  advapi32.dll!_ElfRegisterEventSourceW@12()  + 0x54 bytes 
  advapi32.dll!_RegisterEventSourceW@8()  + 0x32 bytes 
  VSPerf80.dll!CEventLogErrorReporter::CEventLogErrorReporter()  + 0x2c bytes 
  VSPerf80.dll!CreateEventLogErrorReporter()  + 0x25 bytes 
  VSPerf80.dll!_ExecuteCpuidFunction@8()  + 0x1124 bytes 
  msvcr80.dll!__initterm()  + 0xf bytes 
> VSPerf80.dll!__CRT_INIT@12()  + 0xb9 bytes 
  VSPerf80.dll!__CRT_INIT@12()  + 0x206 bytes 
  VSPerf80.dll!__DllMainCRTStartup@12()  + 0x1d bytes 
  ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes 
  ntdll.dll!_LdrpRunInitializeRoutines@4()  + 0x1c7 bytes 
  ntdll.dll!_LdrpInitializeProcess@20()  - 0x37e bytes 
  ntdll.dll!__LdrpInitialize@12()  + 0x88d3 bytes 
  ntdll.dll!_KiUserApcDispatcher@20()  + 0x7 bytes 
  kernel32.dll!_BaseThreadStartThunk@8()  + 0xb bytes 

 

However now i'm getting the following:

 

First-chance exception at 0x06dacd0d (VSPerf80.dll) in Hellgate.exe: 0xC0000005: Access violation reading location 0x02055a4f.

 

And here's the callstack:

 

  VSPerf80.dll!CThunkModuleImports::ThunkModuleImports()  + 0x2c8 bytes 
  VSPerf80.dll!CDataModules:: OnModuleLoad()  + 0xc2 bytes 
  VSPerf80.dll!CModules::ModuleExamine()  + 0xea bytes 
  VSPerf80.dll!CModules::CheckForNewModules()  + 0x7c bytes 
  VSPerf80.dll!CThreadInfo::CheckForNewModules()  + 0x43 bytes 
  VSPerf80.dll!CThreadInfo:: OnFirstThreadCreate()  + 0xd2 bytes 
  VSPerf80.dll!_DllMain@12()  + 0x1a2 bytes 
  VSPerf80.dll!__CRT_INIT@12()  + 0x219 bytes 
  VSPerf80.dll!__DllMainCRTStartup@12()  + 0x1d bytes 
  ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes 
  ntdll.dll!_LdrpRunInitializeRoutines@4()  + 0x1c7 bytes 
  ntdll.dll!_LdrpLoadDll@24()  - 0x1b1 bytes 
  ntdll.dll!_LdrLoadDll@16()  + 0x110 bytes 
  kernel32.dll!_LoadLibraryExW@12()  + 0xc8 bytes 
  kernel32.dll!_LoadLibraryExA@12()  + 0x1f bytes 
  kernel32.dll!_LoadLibraryA@4()  + 0x2d bytes 
> MyApp.exe!__delayLoadHelper2(const ImgDelayDescr * pidd=0x00000000, int (void)* * ppfnIATEntry=0x01385b30)  Line 305 + 0x9 bytes C++
  MyApp.exe!__tailMerge_VSPerf80_dll()  + 0xd bytes Unknown
  

 

Any ideas?

Answer 11

Didier, were you ever able to figure out what was happening?  I'm getting this same access violation in both ntdll.dll and VSPerf90.dll...

Answer 12

I encountered this error just now. 0xc0000005 means an access violation occurred. I tracked it down to mixing of different CRT libraries, thanks to Dependency Walker. A few project dependencies were not properly specified in my Visual Studio solution, and I had a few DLL's lying around from builds using a different version of the compiler. I was compiling against VC7, but saw that the Debug CRT for VC9 was being loaded.

Correcting the project dependencies in the solution and making a clean build solved my problem.

 

Haw-Bin