How to troubleshoot app failing to start with STATUS_DLL_INIT_FAILED (0xc0000142) after Windows 10 "Threshold 2" update (1511, build 15086)

Question

We publish a Windows desktop application (built with Visual C++ 2013 with the v120_xp platform toolset) which worked fine on Windows 10, but we've started to receive reports from users who have installed the "Threshold 2" update that our app now fails to start, showing the following error message:

The application was unable to start correctly (0xc0000142). Click OK to close the application.

The error code is STATUS_DLL_INIT_FAILED, so we're presumably looking for a DLL failing to initialize.

We've made some attempts to troubleshoot this by observing the application starting up in a debugger, and using Process Monitor to see which DLLs are being loaded. The last DLL loaded (on a machine with Threshold 2 installed) is davhlpr.dll. When we watch our application starting up on Windows 10 without Threshold 2, it starts without apparently loading that DLL at all. This suggests that the problem might be something to do with davhlpr.dll, but our code doesn't explicitly depend on that DLL and I have no idea what it is.

Has anyone else seen anything like this?

Does anyone have any ideas as to how we can troubleshoot this? After trying the debugger and Process Monitor, I'm out of ideas.

Attainture

davhlpr.dll seems to be used for WebDAV (msdn.microsoft.com/en-us/library/windows/desktop/dd408159.aspx). The call stack in the debugger might provide some clues as to what's triggering it to be loaded. – Mennonite

Answer 1

We eventually got to the bottom of this. The approach we took was as follows:

1. Tell the linker to delay-load all the DLLs that our application depends on (deferring any initialization problems until after the application had started).
2. Exercise the application until it broke, which turned out to be when comdlg32.dll was loaded to display an "Open" dialog.
3. Create a simple test program that just uses comdlg32.dll to show the "Open" dialog.
4. Run the test program on Windows 10 build 15086 and observe which DLLs it loads, comparing this with the DLLs that are loaded when we trigger the "Open" dialog in the delay-loaded version of our app.

Long story short: it turns out that the failure was due to a Windows component called fwbase.dll (part of the Windows Firewall, apparently) which comdlg32.dll was attempting to load for some reason. Our application included a component named fwBase.dll (part of the AMD Framewave library), and the Windows loader presumably didn't bother trying to load fwbase.dll as it thought it was already loaded. Catastrophe followed shortly thereafter.

At this point, I'm not sure if this is a bug in Windows or what, but we resolved it by renaming fwBase.dll.

Attainture

Answer 2

I was facing a similar issue, where a program compiled & launched without any hitches on Windows 7 (also Windows 2008 Server), but failed for the Windows 10 machine. One trick that worked for me was to "Troubleshoot" the EXE. Using Windows 10:

• Right Click on the executable & select the "Troubleshoot Compatibility" option.
• Then choose "Troubleshoot Program" & then select the "Program worked in earlier version of Windows." (1st check box).
• Select the OS (mine was Windows 7) and proceed to next steps.

Be sure to "Test the Program" and move further to finally select the option to "Save the Settings".

Indiscernible