Stumped on app startup error 0xc0000142
- KVRian
- Topic Starter
- 759 posts since 10 Aug, 2004 from Fredericton NB
On seemingly random user systems, a few get this windows error 0xc0000142 on startup of my standalone app.
The message says "This application failed to initialize properly" but windows header files suggest it's more specifically dll-related i.e. "#define STATUS_DLL_INIT_FAILED 0xc0000142"
Now, using Dependency Walker to check if executable dependencies are satisfied, there's no reported issue loading the auxiliary dll.
There's no pattern of Windows OS, cpu, or other configuration I can identify and I haven't been able to reproduce the problem on several test machines, from XP to Windows 8.
Is there any other way to track down the cause of this error? It's a showstopper for many.
Cheers
The message says "This application failed to initialize properly" but windows header files suggest it's more specifically dll-related i.e. "#define STATUS_DLL_INIT_FAILED 0xc0000142"
Now, using Dependency Walker to check if executable dependencies are satisfied, there's no reported issue loading the auxiliary dll.
There's no pattern of Windows OS, cpu, or other configuration I can identify and I haven't been able to reproduce the problem on several test machines, from XP to Windows 8.
Is there any other way to track down the cause of this error? It's a showstopper for many.
Cheers
- KVRAF
- 7890 posts since 12 Feb, 2006 from Helsinki, Finland
Maybe it's a missing MSVC runtime library, in case you are using dynamic linking? Many applications install the relevant redistributables automatically as part of their installers, so many people will have it available .. which would explain the lack of "pattern" (except there would be a pattern, just a fairly well-hidden one).
- KVRian
- Topic Starter
- 759 posts since 10 Aug, 2004 from Fredericton NB
Ah I forgot to mention - that was my first thought and I ruled that out too. Their installing the vs10 redistributable doesn't help
I statically link all the c++ stuff just for the saved headaches.
Hypothetically I would expect if it needed one of the msvc**100.dll's it'd show up in the dependency walker too? Not sure if I can trust it now.
I statically link all the c++ stuff just for the saved headaches.
Hypothetically I would expect if it needed one of the msvc**100.dll's it'd show up in the dependency walker too? Not sure if I can trust it now.
- KVRAF
- 7890 posts since 12 Feb, 2006 from Helsinki, Finland
Yeah, depends.exe should show those. Just figured they'd resolve fine on any systems where they were installed. I guess you aren't using anything "weird" like custom EXE headers/loaders/packers, etc?DavenH wrote:Ah I forgot to mention - that was my first thought and I ruled that out too. Their installing the vs10 redistributable doesn't help
I statically link all the c++ stuff just for the saved headaches.
Hypothetically I would expect if it needed one of the msvc**100.dll's it'd show up in the dependency walker too? Not sure if I can trust it now.
- KVRian
- Topic Starter
- 759 posts since 10 Aug, 2004 from Fredericton NB
Correct, it's all pretty vanilla. The plugin version does have a delay-loaded dll but not the standalone, which just needs the dll in the same directory.mystran wrote: Yeah, depends.exe should show those. Just figured they'd resolve fine on any systems where they were installed. I guess you aren't using anything "weird" like custom EXE headers/loaders/packers, etc?
Another thing I thought it could be is antivirus programs quarantining the dll or something - this one time BitDefender was quarantining one of my exe's as it was linking lol - but apparently turning them off isn't a solution.
- KVRian
- Topic Starter
- 759 posts since 10 Aug, 2004 from Fredericton NB
edit:
Got it fixed. The initialization in DllMain was returning false for some unforeseen conditions.
Got it fixed. The initialization in DllMain was returning false for some unforeseen conditions.