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
Related
I'm trying to code in Visual Studio 2022 17.2.3 on Parallels Desktop (Macbook Pro 14" M1 Pro). The program was built successfully but when it was running, this exception came up:
Unhandled exception at 0x00007FFE6CFD85F0 (msvcp140d.dll) in Test.exe:
0xC000026F: An internal error occurred in the Win32 x86 emulation
subsystem.
I wouldn't call this a definitive answer, but after a load of prune&test'ing with my code; (I had one project that ran fine, and another that didn't) this code alone would cause the exception mentioned above;
#include <iomanip>
int main()
{
return 0;
}
My exception (before main) was here;
cerr.cpp
#pragma warning(disable : 4074)
#pragma init_seg(compiler)
static std::_Init_locks initlocks;
Switching architecture from 64-bit to x86 helped me.
There is likely some error in x64 WinAPI emulation level. On M1 Parallels uses Windows with ARM support, which uses emulation for x86-64 applications.
I assume you are building and debugging an x64 application, so that's the solution I'm posting here. However, the same principle applies to arm64 debugging if you're running into the same problem.
The problem is your path does not include the debug x64 version of the Visual C++ runtime. So the system tries to grab the arm64 version instead, and crashes because the machine code is the wrong architecture.
The simplest way to fix this is to go to the directory containing the Visual Studio non-redistributable debug libraries (something like C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.32.31326\debug_nonredist - the exact path is slightly different depending on which version of VS you have installed). Then go to the particular architecture you want (x64 here), then the library (Microsoft.VC143.DebugCRT), then copy the file (msvcp140d.dll) into the same directory as the application you are launching (normally something like bin\x64\debug - check your project settings).
This will allow the DLL loader to find the x64 binary first, and load that up. Then you'll be able to debug your application.
I've built a 64 bit version of the OpenH264 DLL in debug mode (with no compiler optimisations) and am calling it in C# (via Unity). I'm using Visual Studio 2017 to attach to the running Unity process and debug my dll.
I can place breakpoints and step through the code, however all values for the code seem to be random (or sometimes null).
For example this is where the debugger reports NULL as the value of a pointer but is stopped on the line after a failed NULL check.
Why is this happening and what can I do to get correct values when inspecting variables?
Maybe due to "At this time, Visual Studio Tools for Unity only supports managed DLLs. It does not support debugging of native code DLLs, such as those written in C++."
1 Please try to switch the Common Language Runtime Support under Configuration Properties :
2 Another potential reason is that the variable is not in the current context:
While debugging, Visual Studio will keep track of every variable in the current context
I compiled a program using freeglut, optix, cuda and other libraries (some of them dinamically loaded). It compiles and runs without problems in Visual Studio but it crashes if I execute it outside Visual Studio. Both release and debug versions work within VS, they both crash without any information on Windows 8 if I try to execute them directly.
I already included all the necessary DLLs, that didn't work.
What could be the problem?
Most such observations are usually coming from undefined behavior -- using uninitialized variable, dangling pointers/refs, overrunning buffer.
You may try to use Application Verifier, with some luck it might rearrange the used memory enough for you to trigger the problem under debug to help corner it.
Also, when it crashes you should get a prompt to launch VS and inspect the problem -- did it not indicate a hint? What was the immediate cause of the crash and what you had on the call stack there?
You can try comparing the environments between visual studio and the default environment.
Dependency walker should identify any missing DLLs.
Get WinDBG, then File > Open Executable and run the program under WinDBG. When it crashes, you will get some more information. My answer here describes an issue in .net, but the concept applies to native C++ as well.
Visual studio runs executables under "debug" mode, meaning a debugger is present.
What does this mean? If you check out the msvcrt implementation, if the runtime detects a debugger is present (IsDebuggerPresent), then heaps preform differently.
What does this mean? It means buffer sizes are "nudged" upwards, it means memory allocations are wiped clean by default (no need to memset), etc.
This can cause a variety of bugs to manifest, or some more subtle bugs to be hidden.
I have a problem with my C++ application. It was developed on a 32bit pc, on Microsoft Visual Studio 2008, and now I am trying to run it on a 64bit pc.
On my 32bit pc it works fine; on the 64bit pc, Visual Studio does not give any compilation problem, but then on execution gives wrong results.
And I have undestood why.
In the code, I define a variable, of tipe "dag", that is a structure for a direct acyclic graph. By debugging the software, I noticed that, although I declared it, later the software is not able to insert data in it, and the debugger says:
CXX0017: Error: symbol "dags" not found
Here's my code:
Dag<int64_t>* dags = new Dag<int64_t>();
dags = getDagsFromRequest2(request, dags);
The very strange thing is that, if I follow the flow inside getDagsFromRequest2() function, I can clearly see that dags variable is full of data: on "quickwatch", it shows 2342 nodes inside it. But when I come back from getDagsFromRequest2() function to this part of the code, debugger says "CXX0017: Error: symbol "dags" not found". How is it possible?
You can also see this screenshot from my Visual Studio debug set.
What could be the problem?
Thanks a lot
There are a few possibilities to consider:
Running in Release builds. Switch to a Debug build.
Using a Debug build that has optimizations enabled and/or debug information disabled. Disable the optimizations and enable the debug information (look in another project for the relevant settings).
A corrupt build of some sort. Clean and rebuild the entire solution.
Memory corruption which is preventing the debugger from displaying the variable. Ensure that no memory issues exist with a tool like Valgrind.
A VS bug. This report for VS2010 seems to suggest a known bug with similar characteristics for example. Ensure all patches and hotfixes for VS2008 are installed.
The variable dags is defined as your code compiles. The error you see is simply related to the debugger. I am guessing it is caused by running the application in Release mode which sometimes causes confusing and wrong watches values. Try changing the mode to debug(there is a drop down from which you can choose the build mode).
EDIT: as you say you are running in Debug mode, my next guess is that this behavior could be caused by stack corruption. Try using valgrind to detect if that is the case. It may take a while to start with it,but it is worth it and will detect if you have some memory corruption.
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.