I have a C++ application. When i press F5 in visual studio application starts and i can debug it. But when I run application from windows explorer and then attach this process in visual studio I see breakpoints can be hit (they are completely red) but breakpoint does not hit. When I see modules window nothing is present there. What is problem?
Verify the code type Visual Studio is configured to load symbols. Attach To Process dialog has Select Code Type option to specify which symbols to load. Here you can select Managed symbols and/or Native symbols.
Also the assemblies should be of same version.
It sounds like the executable code that you are debugging (F5) is not the same as the one you are running from explorer. Check the date of the executable you are running. Also, it may be picking up a different version of DLL if you are using them. Try renaming one of your DLL files and then running from explorer. Use depends.exe to see which modules are being loaded.
Related
I have a native dll which is used by a project in Unity 2019.4.35f1. Since the logic in the dll is complicated I would like to be able to debug it.
From the main answer here
https://answers.unity.com/questions/30620/how-to-debug-c-dll-code.html
I was able to log debug from inside the dll.
From the answer from this thread by Tomas1856, a Unity Technologies superuser, I get that the only way to really debug the native dll code line by line is to attach a debugger to the executable.
https://forum.unity.com/threads/how-to-step-into-a-native-c-dll-in-visual-studio.413387/
The problem is that I am not able to.
I have the dll Visual Studio 2019 project. It is build in debug mode. It's pdb file is here. I have tried changing many project settings from advices I have read on the internet including on stackoverflow. But still when I press the play button in Unity and press the Attach to Process in Visual Studio the breakpoints I have put in the dll code all turn white with an error message "The breakpoint will not be hit. No symbols have been loaded for this document".
I am attaching to the Unity.exe process. I have tried changing the output path for the dll and the pdb.
I am pretty sure I am missing something obvious.
Can someone provide any guidance, please?
After a month I have accidently found the reason. Error Pause was activated. I have logged an error so the Game has paused which makes it impossible to attach to the Unity process. I hope this helps anyone.
In Visual Studio, I want to inspect environment variables of a process launched from it, like in Process Hacker or Process Explorer.
VS gives very advanced debugging capabilities, probably I'm missing something.
Background.
I've got a C++ program built by Visual Studio 2019.
It fails if launched from the Visual Studio IDE, but runs successfully if launched from a .cmd script. Cmd script sets additional environment variables, and I want to mimic this behavior with setting those variables from Project properties -> Debugging. I have done it before, and everything was working.
Now something has changed, and I'd like to figure out what.
Security policies of our company don't allow me to use Process Hacker and ProcessExplorer. If I try to launch any of these programs they are terminated by the corporate soft, installed on my PC.
Also, I'd like to avoid adding code that would retrieve these variables and print them.
So, in Visual Studio, is there something that can show environment variables for me?
Update The issue is indeed in environment vars. Specifically in the way, Visual Studio sets them. No crashes, if I set required variables globally from system control panel. However, something strange happens if I set them via project properties of Visual Studio.
In the debug mode, you can save a process dump (Debug - Save Dump As - Minidump with heap) and then inspect this .dmp file with a hex editor (or Notepad if file is small) searching for an environment variable name.
I have a C++ DLL project (x86) that I need to debug.
This DLL is consumed by an exe.
I can easily attach the DLL project in VS2017 to a native exe (x86).
When I set breakpoints in the C++ DLL project in VS2017, these break points are hit.
This is the normal, desired behaviour.
Now I have attached the C++ DLL project to a .NET exe (compiled as x86).
Break points are not hit, and I don't have any idea why that doesn't work like with a native exe.
I have unchecked the option "Use Application Framework", but that didn't change anything.
I have also tried the option "Enable native code debugging" without any success.
Also, I have tried to attach it to a Debug version of the NET exe and to a Release version of the NET exe.
I can see that VS2017 attaches to the correct process as when I close the NET exe, VS2017 goes out of debugging mode.
However, breakpoints are not hit.
Is there anything special that I have to take care of?
Most likely, the managed .exe has not loaded the native DLL. Or it has loaded an incorrect build of the DLL, not the one that you’re debugging.
To troubleshoot, add __debugbreak(); call in your native code. That kind of breakpoint is very unlikely to be ignored, unless you mess with structural exception handling. Windows will show you a message offering to attach a debugger, you can choose existing instance of visual studio. Once attached, “Modules” window will show you exactly which build of the native DLL it loaded.
The best way to solve that permanently is add two projects in a single visual studio solution, setup dependency, and ensure the DLL output location is where the EXE looks for the library. I do it all the time in VS2017, with native code debugging enabled I can set my breakpoints in either managed or native code, which helps a lot debugging the interop.
I'm using VS2010. I have an unmanaged EXE written in C++ that's using a .NET COM component which is also part of the same solution. I know that the COM object was created successfully because CoCreateInstance returned without an error. Yet, the component symbols aren't loaded (I can also notice that by not being able to create breakpoints in the .NET project source files), so I can't step into the code of the object's methods.
I tried to copy the .NET DLL's PDB into the same output directory of the EXE and it also didn't help. All projects in the solution are x64 and Debugging mode is set to Mixed.
If that matters, the DLL was registered using the command regasm /codebase
Any ideas? Thanks.
Yes, you have to enable managed debugging. One problem with Visual Studio (at least 2008 and 2010 -- don't know about later versions) is that you can only debug Native and Managed code at the same time with 32-bit processes. With 64-bit processes, you have to debug one type or the other, but not both at the same time. I suppose you might be able to spin up another instance of Visual Studio and debug the Native with one instance and Managed with the other.
Under your project settings, go to the "Configuration Properties" - "Debugging" page. On the right go over to Debugger Type and select Mixed.
I am trying to debug a project developed in visual studio 2010 and it loads VC++6 (VisualStudio 6) DLLs. Unfortunately I am unable to see the VC++6 DLL process under "Attach to process".
When I searched on the net I found the http://msdn.microsoft.com/en-us/library/cta4x5hc(v=vs.80).aspx article and it suggested to add /ASSEMBLYDEBUG when building vc++6 DLL. But then I get "Command line warning D4002 : ignoring unknown option '/ASSEMBLYDEBUG' ".
So can some one tell me whether it is possible to debug a VC++6 DLL from visual studio 2010.
regards
Upu
you do not need to attach. DLL is loaded into host process. So just start debugging you project that loads the dll. if you have pdb and source code of the dll, you will be able to set breakpoint in dll code.
The DLL's wont show up as a "process" in the debugger, they're part of the process that loads and uses the DLL's (i.e. the main application).
So yes, you can debug them with VS2010, you can just launch the app written in VS2010 (or attach to it in the debugger) and you should see the DLL's loaded in that.