c++windowsdllwindows-10-desktop

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

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.

Solution

  • 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.