How to troubleshoot problems starting an application with STATUS_DLL_INIT_FAILED (0xc0000142) after updating Windows 10 Threshold 2 (1511, build 15086)

We are publishing a Windows desktop application (built on Visual C ++ 2013 with the v120_xp platform toolkit) that works fine in Windows 10, but we started receiving reports from users who installed the Threshold 2 update, which our application now doesn’t start, showing the following error message:

The application could not start correctly (0xc0000142). Click "OK" to close the application.

The error code is STATUS_DLL_INIT_FAILED, so we are apparently looking for a DLL that is unable to initialize.

We tried to fix this problem by monitoring the launch of the application in the debugger and using Process Monitor to find out which DLLs are loading. The last loaded DLL (on a computer with Threshold 2 installed) is "davhlpr.dll". When we look at how our application runs on Windows 10 without Threshold 2, it starts without loading, generally speaking, this DLL. This suggests that the problem may be related to davhlpr.dll, but our code is clearly independent of this DLL, and I have no idea what it is.

Has anyone else seen something like this?

Does anyone have any ideas on how we can fix this problem? Having tried the debugger and Process Monitor, I have no ideas.

+5
source share
1 answer

In the end we reached the end. The approach we took was as follows:

  • Tell the linker to delay all the DLL files that our application depends on (delay any initialization problems until the application starts).
  • Run the application until it breaks, which turned out when comdlg32.dll was loaded to display the Open dialog box.
  • Create a simple test program that simply uses comdlg32.dll to display the Open dialog.
  • Run the test program on Windows 10 build 15086 and see which DLL files are loaded, comparing this with the DLL files that are loaded when the "Open" dialog is launched in the delayed version of our application.

In short: it turns out that the failure was due to a Windows component called "fwbase.dll" (apparently this is part of the Windows firewall) that comdlg32.dll was trying to load for some reason. Our application included a component called "fwBase.dll" (part of the AMD Framewave library), and the Windows boot loader did not seem to try to load the fwbase.dll file because it thought it was already loaded. After this, disaster soon followed.

At this point, I'm not sure if this is a Windows error or something else, but we decided to rename it fwBase.dll.

+4
source

Source: https://habr.com/ru/post/1236239/


All Articles