This is kind of a stupid question I guess, but I have a library which is included and used in a project, compiled as a .dll. Everything compiles fine. When I reach a function in this library, I get System.AccessViolationException and I cannot enter into it while debugging because it says the symbols are not loaded.
I have looked in the modules window, and I cannot find my .dll
Why?
Thanks.
This may be a managed/unmanaged debugging issue. You won't see unmanaged DLL's if you are doing managed debugging, and vice-versa. The "automatic" option where VS tries to guess what kind of debugging you want doesn't always work.
Try attaching to the process after it is loaded and then specify both managed and unmanaged debugging in the dialog that pops up when you choose the Debug->Attach To Process menu option.
Related
I'm using QtCreator with the visual studio 2015 kit on windows 8.1 to build a program I developed and tested on Linux, on linux it works correctly, but on windows it's just crashing immediately, and I have no idea what to look for.
The only external libraries, aside from QT I'm using are opengl and glew, so I don't think it's those.
Is there anything that's known to work in GNU C++ but crash immediately in MSVC?
Usually this kind of crashes have absolutely nothing to do with your program. It's an external library linking issue. I had this issue recently with the OpenSplice DDS library. I linked to a library that caused a segmentation fault before anything started. I resolved the issue by linking the pre-compiled libraries 1-by-1, and check each if that fixes the program.
What I recommend you to do is: Remove the libraries and resources you're linking to gradually, until your program starts and prints "Hello world" from the first line of main().
Another way to go is, make a new empty program, and link the same resources you're using in your program. This is easier, as it doesn't involve modifying your program.
This is what I would do.
Start by rebuilding the entire solution or project from a clean state. Just in case this is just some weird dependency issue that resulted in something not getting recompiled. Never hurts.
As Neil said in the comments for the question, the crash is possibly coming from a global variable who's constructor runs before main or WinMain. Are you sure you don't have something declared as "static" or at global scope that might have a constructor?
Now do the following:
Open Visual Studio.
From the menu, select File->Open->Project/Solution...
When the file open dialog pops up, select the EXE produced by Qt
Creator. (That's right - you are opening the EXE as a project). This directory is typically one folder level above the Qt project (..\build-yourapp-Desktop_Qt_5_7_0_MSVC2015_32bit-Debug\debug)
Now press the green arrow to start debugging (menu->Debug->Start
Debugging). If all goes well, your program will fail early and
Now chances are high that the program is not going to run at all under Visual Studio because Qt Creator doesn't copy all the Qt*.dll binaries to your build directory. You'll get a bunch of dialogs popping up saying that "The program can't start because Qt5-XYZ.dll can't be found". This is easily fixed by updating your PATH environment in any of the following way to include your Qt5.x.0\5.x\msvc2015\bin folder to your PATH.
You add it from the command linke and then re-launch devenv.exe from the command line.
You can add it globally from Control Panel->System->Advanced. Then restart Visual Studio from the Windows desktop.
With the EXE debug project open from within Visual Studio, just right click on the project name (not parent solution) and a dialog will popup that allows you to edit startup settings. One of which is the Environment.
And that should do it. From there you can start the debugger on your EXE, set breakpoints as needed, and analyze the call stack on crash.
It's really easy: build all the libraries you use, including Qt, with debug information (those can be release builds as long as the PDB files are generated). Then run your application under a debugger (e.g. F5 under Qt Creator), and it will stop at the point of the crash.
The code that runs before main and is known to cause trouble will be the global object initialization: you're likely running into the static initialization order fiasco.
Another cause for the problem could be stackoverflow. In Linux, the stack size by default is usually 8 MB whereas in Windows it's just 1 MB.
Try to link with /STACK:8388608 switch. If it works, you might consider allocating more data on the heap and stay with the default stack size of 1 MB.
Assume this scenario: An application (app.exe) is using multiple .dlls. I am debugging a function, bugged_function() from one of the .dlls used by the app: util.dll. While I am debugging bugged_function() from this I realize that something in the code is wrong and changes have to be made.
Steps to perform normally:
1. close app.exe
2. modify code in the function
3. recompile util.dll
4. rerun app.exe
What I want:
Bypass step 1 and 4. To do that I need to unload in some way, if possible, util.dll library so when compiling it can be overridden. The the application must somehow reload the library again.
EDIT 1:
I do not know how bugged_function() is called. Assume that I only have access to the source code of the library util.dll used by app.exe.
EDIT 2:
I am using Visual Studio 2010, and when I debug, I attach to app.exe process.
If the application is using the dll via run-time dynamic linking, it could be unloaded (FreeLibrary or similar), then reloaded (LoadLibrary or similar).
If the application is using the dll via load-time dynamic linking, I think you're out of luck.
Edit: I misread the question slightly. Since you can't modify app.exe, you'll have to rely on built-in functionality of that application for runtime loading and unloading, if it has it. That depends totally on the application.
Visual studio can edit and continue. So if you are at a breakpoint, you can make the changes you need to then continue your debugging. Visual studio will compile and apply the changes while maintaining state.
Edit: fixed edit and continue naming.
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
Got a big MFC C++ project. Our VS version is 2008. It loads a regular dll (for some optional functionality) and calls exported functions from it. When debug through the MFC app and get to the point where we call the exported function you can't step into the dll function. Is there a way to get debugging inside the dll functions. Even if I've got the dll project included in the C++ solution, it doesn't seem to "see" the dll code.
Edit: We've got a number of extension dlls and debugging into them works just fine. This is a straight dll, no mfc, /clr option set so we can call into some managed code. The class that consumes this dll, loads it, then uses GetProcAddress to find pointers to the exported functions. Here are examples.
typedef void (*FP_OnEditOptions) ();
to prototype the function.
then
m_fpOnEditOptions = (FP_OnEditOptions) GetProcAddress(hInstance, "Direct_Edit_Options");
to get the proc pointer, then
static void OnEditOptions()
{(*m_fpOnEditOptions)();}
to call it.
When debugging, get to the call to it, hit F11, and it calls it, but doesn't step in.
Yes, the dll has debug option, and when the module is loaded, the symbols are loaded from the appropriate pdb file.
Thx,
Andy
Debug + Windows + Modules. Locate the DLL in the list and right-click it. Symbol Load Information tells you where the debugger looked for the .pdb file. Make sure you get it there.
After update: it is very likely that with /clr enabled that you are actually running code that was compiled to IL and just-in-time compiled. Just like managed code. You'll need to switch the debugger to Mixed mode debugging. Project + Properties, Debugging, Debugger Type = Mixed.
Look under Tools->Options->Debugging->General
There are a couple of options which may help - I'm not sure which one exactly you'll need. The 2 obvious ones are:
Disable "Just My Code"
Disable "Step over properties and operators"
You might also try putting a breakpoint inside the function that's being jumped over. That should force the debugger to stop at that code.
Im using vs 2003. When I try to debug some program that uses several dll files i can debug
(put breakpoint - without question mark) only on the cpp files of the project that creates
the dll and was the last one that i compiled . breakpoints located on others dlls (that are part of the program and located in the same solution) are marked with question mark and the debugger doesnt reach them at all.
how can i solve it ??
thanks,
liran
You must build these dll's as debug and make sure they have the correct symbols in them? just a guess.
You can load up the symbols from other assemblies by specifying the symbols path to them in Visual Studio. I'm not sure if the feature is in VS2003 or not, however.