Writing a C++ DLL to use from Unity3D.
If I build the DLL as release, I currently get some undefined behavior nonsense. If building as debug build, the following popup shows:
Unfortunately the error redirects into the vector class and not the place where it is actually used in my own code.
I know what DLL function causes this, but I cannot find out why this happens because there is a lot of vector handling. I do suspect some multithreading issue.
However how do I find out which particular line, aka which assert failed?
I do not seem to be able to catch asserts with the try-catch block.
Huge thanks in advance :)
Turns out it is possible to debug the Unity editor as a whole with attached DLLs.
Find out where the actual editor is (in the rightclick menu of the installs tab in Unity Hub)
Open that EXE with Visual Studio (literally the "Open project" selection)
Go to the solutions properties -> parameters and add:
-projectPath "PATH_TO_YOUR_UNITY_PROJECT_DIRECTORY"
Debug -> Start Debugging (or F5)
If you get an assertion etc. click "Retry".
Step 3 is important because for whatever reason, Unity does not show the "open a project" option if started as debug and just closes itself instead. That's what made me think that external debugging is not supported.
I have an executable that is built with MSBuild and CMake, because I want to stay out of Visual Studio unless I am debugging. I have a callback in which I can't tell if it is working correctly or not, so I want to debug it. The problem is if you open an exe with devenv, it just appears to open the entry point of the application, it doesn't actually load the source code that would let me set a breakpoint on the callback, and since it is a callback, all my applications main function does is register the callback, so I have no way of breaking on an event with the callback I want to debug.
I know I could do hacky things like put the callback code in main.cpp and set the breakpoint there, or I could just debug the solution that CMake generates, but what I want to know is if there is a way to just simply debug the application to where I can open all source files associated with the executable without opening the solution, just the executable? The reason I want to do it this way is mainly for speed, a dummy solution runs significantly quicker on my machine than a full on solution, and it allows me to work in a text editor that is much faster than Visual Studio.
The WinDbg tool is that path I could know if you don't use the VS IDE as the debugging tool, it can help you to debug/load source code or others.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556911(v=vs.85).aspx
I'm trying to debug a pre-configured and optimized C++ project. I disabled "Optimization" under C++ -> Optimization -> Optimization. However when I step through code sometimes it jumps around randomly and often it doesn't show the proper values for local variables.
As others have said, you need a build with optimisations switched off and debug info being generated. I assume you're already generating a PDB for your release build.
The key here that there is no 'debug mode' - just different project settings. So it's possible (likely even) that while some of the settings in the debug config cause your build to fail, others (possibly including switching off optimisations and enabling debug info) may work fine.
I suggest you experiment with changing the properties one at a time. It's likely that you can take your working config, switch off optimisations, and it'll build fine. If so, you can keep the modified vcproj for yourself or create a new project config containing the changes, to share with your colleagues.
(sorry, not enough rep to post as comment)
I'm new to windows development, and my programming skills are not that strong (I'm with EE background, major is semiconductor), but at least I understand the fundamental of C/C++.
Regarding Windows C++ project, I found that I can debug under both debug and release builds (by adding break points, and reading the value of variables) in visual studio. I did some research, and I found that as long as there is a PDB file, I can do the debugging. However, will the "debug-able" release build impact the performance?
I also read about disabling debug in visual C++ projects. If I disable debugging, will the performance of a release build be better than a debug-enabled release build?
Sorry for my broken English.
No, it makes no difference. The linker's /DEBUG option is simply turned off by default for the Release build. The PDB it generates isn't all that useful for debugging, the optimizer that's turned on for the Release build makes a big ole mess of your debugging session. You'll have trouble setting breakpoints on some statements, see single-stepping acting weird (the code highlight moving around unpredictably) and the debugger not being able to show you variable values.
Still, sometimes you really need the PDB file, invaluable when you get a minidump back. Recorded by a customer when your program crashed and burned a thousand miles away. You need to plan for that, pretty important to generate the PDBs and store them so you'll have them available when you analyze the minidump.
Enabling PDB generation doesn't affect code generation, so the performance of your Release code won't change if you enable PDBs.
(Do note that debugging of optimised code is not as reliable as debugging non-optimised code... you'll find that the current line seems to jump around, and that you can't always rely on the reported values of variables.)
A binary can be debugged in windows with or without a PDB file. A PDB is a database of sort which provides information to the debugger such as the name of locals, the type of locals, offset to source mapping, etc .... None of this is strictly necessary to debug it just makes it a whole lot nicer. If you were so inclined you could debug the assembly directly with no PDB.
Hence there is really no concept of "disabling debugging". Really it comes down to whether you build a Debug / Release build. A Debug build is generally much more debuggable than a Release build because the compiler will take care to keep interesting locals around and insert no-ops to make stepping nicer. Release builds are all about performance of the final output and will sacrifice easy debugging to achieve it
I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options: