Release version crashing due to msvcp120d.dll - c++

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.

Related

Cause of WP8.1 release build exception: "System.IO.FileNotFoundException: The specified module could not be found"?

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.

What causes the Visual Studio Debugger to make some issues not reproducible?

Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe

libx264 in Visual Studios 2010 - Memory error in Release Build

I am building an application and using the x264 library as an encoder. I have built the library for my windows system using MSys/MingW. The library works fine under debug build (note both debug and release builds are using the default VS2010 settings). However, under release an access violation error is thrown at the first call to the x264 library, specifically:
Unhandled exception at 0x00905a4d in StreamTest.exe:
0xC0000005: Access violation.
The error is thrown at this line:
x264_param_default_preset((params), "veryfast", "zerolatency");
While I was figuring out how to compile the library I came across a lot of talk about memory alignment in Windows/Visual Studios and how it wasn't particularly compatible with the alignment expected by x264. For example when compiling in MSys I had to enable --enable-memalign-hack. I am wondering if the source of this error might stem from a memory alignment issue which only manifests itself through some setting in my release build. Unfortunately I know almost nothing about the specifics and so have come here.
Can anyone give me some more information regarding the memory alignment issues and any Visual Studio settings which might cause this? Any other tips/pointers to fix this issue are very welcome.
Thanks.
Edit
From answer below:
From the linked SO question I get the impression he added "build with debugger info" to the OpenCV build? Since I'm building the x264 library through MSys with G++ I'm not sure I can do this. I have checked the build settings for my project, and under both release and debug it has debugger info. Not sure if I missed something in that post, please let me know.
I tried the application verifier. It seems that x264 is trying to execute code from non-executable memory as per the App verifier output:
VERIFIER STOP 0000000000000650: pid 0x1B18:
Attempt to execute code in non-executable memory (first chance).
0000000000905A4D : Address being accessed.
0000000000905A4D : Code performing invalid access.
000000000021EA90 : Exception record. Use .exr to display it.
000000000021E5A0 : Context record. Use .cxr to display it.
Anything to be gathered from this output?
Thanks again.
Refer to a similar issue here, see if that helps you too.
EDIT
Post that you also want to run your application through AppVerifier
EDIT
In my opinion release "Build with debugger info" amounts to turning on -g switch together with optimization switches and turning off any DEBUG macro. Also if you debugger attached (use Gflags ) to start your process with debugger (grab a copy of windbg and use that to debug).
When the Appverifer stops your process use .cxr command to get context information. That should help pointing out the issue.

how can i diagnose exception in window 7 release mode compilation with VC 2008

i have strange problem , my application (exe) is working fine in debug mode in windows 7
but stop to work with exception when compiling in release mode .
how can i debug the program to find what is causing the exception this is application with more then 300,000 lines of code ..
Compile in Release mode but create the .pdb files: How to generate PDB’s for .net managed projects in release mode?
Deploy the .pdb files to same folder as the .exe.
Then attach to process.
Check the projects settings which are different for debug and release modes, maybe you will find an answer there.
Compile release mode with debug information and turn off optimization. You will have debug version compiled with release defines. If it fails the debugger will show you bad place.
Just turn off optimization. Once upon a time that was an issue for me. In this case it will be really hard to find out the cause.
Create PDBs, it can be done for native C++ too.

Visual studio release build

I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx