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.
Related
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
My code is crashing in the Release configuration but not the Debug configuration. It's only doing this as I exit the program as the very last line 'return(0);' executes. I'm working in the Visual Studio development environment and when it crashes, VS studio offers me the option to 'Debug' the code. When I select that, it leads to an error dialog that pops up saying:
Unhandled exception at 0x00007FF851A0512D (msvcp120d.dll) in myapp.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
When I select to 'break' when this exception occurs, it highlights the following function in the xstring file:
void _Free_proxy()
{ // destroy proxy
typename _Alloc::template rebind<_Container_proxy>::other
_Alproxy;
this->_Orphan_all();
_Alproxy.destroy(this->_Myproxy);
_Alproxy.deallocate(this->_Myproxy, 1);
this->_Myproxy = 0;
}
And, especially, the line '_Alproxy.destroy(this->_Myproxy);' is highlighted as the culprit.
I thought the issue might be that my 'release' code is somehow linking to the 'debug' msvcp120d.dll library since that's highlighted in the 1st dialog that pops up - but that may be just because I start using the VS debugger to ID this problem. But even if that is the problem, I'm uncertain how to tell VS to compile with msvcp120.dll for the Release configuration and msvcp120d.dll for the Debug configuration.
(For the record, I'm generating all my code using the 'Multi-threaded DLL (/MD)' flag in the Release configuration and the 'Multi-threaded Debug DLL (/MDd)' in the Debug configuration)
The kicker is that when the Release version crashes, the process enters a 'suspended' state and I'm unable to fully kill it via task manager. And then I can't even recompile a new Release version without restarting my computer!
I don't know how to isolate this problem. Can anyone advise me on how I might fix this?
Update
The code for this project is quite large - so distilling it to a minimal version that exhibits the same behavior, while usually a valid way to track a bug, would be a pretty big task. I was hoping that there was some method to log the processes and figure out which one is calling msvcp120d.dll #Niall, I generated the dependency graph and it is huge. Without giving away anything proprietary, attached is a global view of the graph.
Dependency graph of entire solution
Is there any tool to track which is calling msvcp120d.dll?
#Niall Thank you! The software at Dependencywalker.com was fantastic. I was able to use it to determine the library causing the problem and track down the error. It turns out that I had previously (months ago, dumbly) set a system path to the debug version of that library. So even though my project was properly directed to link to the release version of the library, at runtime, my executable was linking to the debug version of the *.dll file!
I deleted the path variable and now make sure a copy of the proper *.dll file is in my Release or Debug directory. Then it all runs and shuts down fine.
Thanks to all who provided assistance.
I am trying to step through a C/C++ program (MapServer) in Visual Studio, but I cannot see the local variables.
I created a new project by adding the main .exe I built from source. I can set break points and step through the program without problem, but I cannot see what is stored in any of the variables. I am running all this on a Virtual Machine - the host OS is Windows 10, and the VM is Windows 7.
The program is:
built as a debug release
has no optimizations
the symbols load fine
I am fairly certain it is due to it being a x64 bit release, as I can use the exact same approach for a x32 build and see the variables.
Example of the x32 debugger (the first 5 variables are correct - the others are unset):
Example of x64 debug session (note the program works fine):
I thought it may be due to VS2008, so I also tried in VS2015, but had similar (failing) results:
Trying to access variables in the Immediate Window produces:
// working VS2008 x32 build
map->name
0x00ffcb40 "WFS_server"
// VS2008 x64 build
map->name
0x0000000000000000 <Bad Ptr>
// VS2015 x64 build
map->name
0x0000000000000000 <NULL>
Am I missing some debugger setting in Visual Studio to set the debug project to x64? Or is there some casting issue in the source code that produces this?
Any pointers appreciated..
The above was caused by stdrup being deprecated on Windows, and the heap becoming corrupted.
The MapServer issue on GitHub can be seen at https://github.com/mapserver/mapserver/pull/5277
This question also describes a similar issue: Heap corruption with strdup
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.
Having a c++/cli project and it's a windows application. In debug mode we didn't have any problems but after taking it to release mode this error start up. I searched and found some forum-answers but couldn't help me solve this problem.
Please help me ....
Error :
An unhandled exception of type 'System.TypeInitializationException' occurred in Unknown Module
Additional information: The type initializer for 'Module' threw an exception.
In a C++/CLI project, the <Module> class is special (note the angle brackets). It is a hidden managed class that the compiler generates to give all of your functions that are not methods of a class a safe home. Required because the CLR does not support free functions like C++ does.
The type initializer for <Module> is extra special, it runs very early at the start of the program. That's where the CRT gets started and any static objects in your code get initialized.
So the basic diagnostic you have is that the initialization of a static object in your code failed. That this happens at startup and only happens in the Release build is very, very painful. The debugger doesn't let you step through this code and of course you don't have good debug info to start with in the Release build. With some luck, the root cause is a C++ or SEH exception that didn't get handled. Debug + Exceptions, tick the Thrown checkboxes. The debugger will stop when the exception is thrown.
Does the machine where the application is running has all the required dlls??
I strongly believe that you are missing some interops in the local directory
I had the same problem and it got fixed after I install Visual Studio 2015 Redistributable x64 and x86.
Install VS C++ 2015 Redistributable (both x64 & x86)
Make sure you install both the x64 and x86 versions.
Hope this should fix the issue.