I know that mixing DLLs from different MSVC is bad and should be
avoided...
I have a 3rd party DLL (XXX.dll, XXX.lib, XXX.h) which is implicitly linked in my application.
The original setup is:
My application (built with VS 2015)
XXX.dll (built with VS 2008)
x64
Windows 7
And it worked!
However moving to Windows 10:
(My application is re-built with VS 2015 and still with XXX.dll)
Now the application keeps crash with access violation
Exception thrown at 0x000001EF05A2BBB9 (XXX.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000074A3A68.
Here is the call stack:
XXX.dll!000002a7eeb6bbb9()
user32.dll!UserCallWinProcCheckWow()
user32.dll!DispatchMessageWorker()
mfc90u.dll!AfxInternalPumpMessage()
mfc90u.dll!CWinThread::Run()
mfc90u.dll!_AfxThreadEntry(pParam=0x000000d5452fd890)
msvcr90.dll!_callthreadstartex()
msvcr90.dll!_threadstartex(ptd=0x0000000000000000)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
As usual, "3rd party" support is very unhelpful...
What could cause this problem suddenly on Win 10?
What kind of mistake could XXX.dll!000002a7eeb6bbb9() make to mess up memory?
I was thinking about the problem mixing different CRT and it is the orignal question:
different behavior when mixing DLLs from different MSVC
Related
My application throws this error on the start
Unhandled exception at 0x00007FF8DC378C34 (msvcp140.dll) in TimexLPRService.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
In Stack Frame control I see msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t *mtx, const xtime *target)
const xtime *target is null (it shows in locals control)
If I start application manually it tells I have error on startup (error code 0xc0000142).
I have msvcp140.dll and vcruntime140.dll near the executable
I build my application with Visual Studio 2019 and vcpkg
I want to know how I can debug this problem to understand what went wrong or what possible causes of such problem
There can be different reasons.
#1 (update)
You may have a null pointer exception somewhere:
Access violation reading location 0x0000000000000000
To fix, try running your code using IDE's debugger, and it should break on the first access violation.
#2
The "MSVCP140.dll" name is shared between multiple versions, for example MSVC 2015 and MSVC 2019.
As long as the latest redist is installed, there should be no problems.
But crashs happen, for example if:
Your App was built with MSVC 2019.
But an older version is installed on the system (like 2015 redist).
Or, the correct redist is installed, but the wrong .dll version is placed beside your executable.
I created two new C++ projects using VS2010, one is DLL and one is console app. I flagged the class in DLL for export and the console app reference the DLL project. Very simple things and it works.
But, when I changed the DLL toolset to v90 (VS2008 installed), I am getting Access violation reading location error.
It seems to me, the two C++ projects must be compiled by the same toolset v100 which both targets .NET4.0. If there is a mismatch between the two, it causes access violation error.
Does anyone know how to resolve this? I could move the source code from DLL project into the console app project, but, that's rather ugly.
Is this a limitation of lower version of .NET? Maybe higher version of .NET has better backward compatibility on C++ dlls?
Thank you
I'm posting a problem I recently encountered while developing a Windows Phone 8.1 release mode app. Fortunately, I was able to solve the problem, which I would like to share via StackOverflow.
The problem encountered was as follows:
I have a Windows Phone 8.1 (WP8.1) application which has a Windows Runtime Component.
When compiled in debug mode, the application works perfectly.
When I build it in release mode, the application links and runs. However, when the C# portion attempts to instantiate the Windows Runtime Component class, the app throws a System.IO.FileNotFoundException exception, caught by Application_UnhandledException() in App.xaml.cs:
System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at System.StubHelpers.StubHelpers.GetWinRTFactoryObject(IntPtr pCPCMD)
. . .
I attempted to debug the release version, disabling all optimizations in the project, but the results were not conclusive. The breakpoint I placed on the native code constructor was never hit by the debugger (I switched debugging to "Native Only" in Properties>Debug).
Reviewing the compiler and linker settings did not show anything out of the ordinary. What was the cause of the problem?
The reason for the System.IO.FileNotFoundException being thrown was because the list of libraries to link in release mode (Linker>Input>Additional Dependencies) included SQLite3D.lib (the debug version of the SQLite library) rather than SQLite.lib (the release version):
API.lib;Internals.lib;JSON.lib;sqlite3D.lib;%(AdditionalDependencies)
This was enough to prevent Windows Phone 8.1 from loading the Windows runtime component DLL to invoke the class constructor.
The solution was to link the release lib rather than the debug one:
API.lib;Internals.lib;JSON.lib;sqlite3.lib;%(AdditionalDependencies)
This explains why the app works perfectly in debug mode.
My experience in C/C++ has taught me that mixing debug and release libs can be problematic. An example is allocating memory in a release mode DLL and deallocating the memory in a debug mode DLL, because there are two different memory management systems at play here. The case at hand illuminates another reason for not mixing release and debug DLLs/libraries.
I am working with a series of DLLs that are loaded as individual CView classes in a MFC application using LoadLibrary from WinBase.h.
Building for release works and all the various DLLs load. However, when I do a debug build with Visual Studio 2010, one (and only one) of the DLLs fails to load. All the DLLs are similarly designed. Using the debugger, I can see that LoadLibrary is getting error 998 (ERROR_NOACCESS, Invalid access to memory location.). I turned on break at access exception and the bad access appears to occur within the strcmp assembly at the instruction cmp al, [ecx] (ecx is 6D655277 at this point).
However, I am not sure how to further track down this bug (and Visual Studio tends to crash whenever I break at the access violation, making it even harder).
Any suggestions or past experiences are much welcome.
I have a large C++ application running in a Win32 and a x64 Version (using Windows XP x64). When debugging the x64 Version, after each code change the first debug session i start stops with
Unhandled exception at 0x77ee5f3c in myapp.exe:
0xC0000005: Access violation writing location 0x0000000000030c90.
The callstack shows endless recursive calls in ntdll:
ntdll.dll!0000000077ee5f46()
ntdll.dll!0000000077ef31ed()
ntdll.dll!0000000077efbc0b()
ntdll.dll!0000000077f2539e()
ntdll.dll!0000000077ee5f46()
ntdll.dll!0000000077ef31ed()
etc.
When after this i choose "Stop Debugging" and then "Start Debugging" usually everything is fine and the problem does not occur again until i compile some code and link or if i restart Visual Studio.
The addresses you listed are 32 bit addresses. This suggests that VS is trying to use its 64-bit debugger on a 32-bit process.
Possibly you have a mixture of 'Win32', 'x64', and 'Any CPU' build platforms in your solution. Make sure your 'active build platform' is consistently defined. The .net stuff claims 'any cpu' on the surface, underneath it has some affinities for 32-bit operation.
Turning off 'Edit and Continue' debugging seems to help this kind of thing too.