Visual studio tells me that 64-bit managed+unmanaged code debugging is not supported. Has anyone managed to resolve this problem?
I've seen this problem too with the 64-bit debugger. Do you definitely need to debug both at the same time?
If not, when you need to debug native code you could run the managed application and the attach the debugger manually selecting "Native Code" as the debug type (as opposed to Automatic which might select both Managed and Native).
Ctrl+F5, once running,
Debug->Attach to Process.
In the attach to: box select "Native code".
Make sure in the processes box your vshost app is highlighted.
Press "attach".
Now your break-points in your native cpp code should trigger and the debugger will kick in.
Related
I am writing C# plugin (DLL library) for a native\unmanaged application. The problem is that when I start debugger, the application runs and almost immediately exits (probably because my DLL is not loaded on application startup, but later). Checking "Enable native code debugging" helps, but significantly slows down application performance which is undesirable, because I only want to debug my C# code. Is there any way to debug DLL without enabling that option? I'm using Visual Studio 2015 Community.
I've figured it out. :)
Enable "Use managed compatibility mode" in Options->Debugging->General.
I have a WinForms managed application which calls into a native C++ dll. I have enabled mixed managed and unmanaged debugging for the project and I'm able to step into the unmanaged code when debugging the project.
I'm interested in JIT debugging because it's much faster to run the debug build outside the debugger and start debugging only after some assertion is violated. JIT Debugger works fine, when the exception is raised in the managed code. It also work when I JIT debug a standalone C++ application. But whenever an exception is raised inside the unmanaged code which is invoked from the WinForms application, the JIT debugger quits immediately after I initiate the debugging session. I have enabled all the JIT debuggers in Options/Debugging/Just-In-Time list. Is this scenario supported at all?
UPDATE
I've run some more tests, and I can see that
This problem is not specific to WinForms applications. JIT Debug also fails when a managed console application calls into a native dll, which raises an assertion exception.
The problem does not seem to depend on framework version. I tried versions 3.5, 4, 4.5, 4.6.
The debugger also fails to break on an assertion exception in the unmanaged code, when I attach the debugger to its managed host application.
I have gone through this situation before. I think the problem is that the exception is uncatched by debugger.
I did the following and maybe this would be helpful.
Click Debug->Windows->Exception Settings.
Or you just search "exception" at quick Launch.
You may find a lot of exception is not catched by default setting.
I feel stupid. The solution was right in front of me.
There's an option in Visual Studio Just-In-Time Debugger dialog. It's called "Manually choose the debugging engines". Both Managed and Native engines have to be selected.
My setup:
Application.exe (Visual Studio 6.0 C++)
Component.dll (Visual Studio 2010 C#)
Application.exe uses Component.dll
I want to be able to debug my Visual Studio 6.0 C++ application and the Visual Studio 2010 C# component that it uses at the same time but I'm not sure if this is possible or not.
I tried to launch the application from Visual Studio 6.0 and attach to that process (Application.exe) in my Visual Studio 2010 component solution but when I go to attach to the process (Application.exe) it is greyed out. I tried switching the Attach To: to Native but this does not allow me to attach to this process. My Application.exe is still greyed out in the window.
Is it possible to do this and if so how?
There can be only one debugger attached to a process, that's why the selection is grayed out. You have little use for the VS6 debugger, it doesn't know anything about managed code. You'll have to debug this from VS2010. Right-click your C# project, Properties, Debug. Select "Start external program" and select your C++ .exe. Tick the "Enable unmanaged code debugging option".
Set a breakpoint in your C# code and press F5 to start the .exe. The breakpoint indicator will turn solid as soon as the C++ code loads you DLL. Debugging the C++ code might be possible too although you're working with a .pdb from the previous century. You cannot single-step from the managed code into the C++ code, you have to set a breakpoint.
You cannot attach two different debuggers to the same process.
Instead, you can attach it only to VS2010, but attach it as both managed and native.
I have an old DLL written in Visual Studio 6 which I am calling from C# written in Visual Studio 2010. The DLL is not working properly and I want to debug into it. How can I do this? I have the source code project but cannot see how I can step into it.
Note: When I say "doesn't work", the call to the DLL succeeds and it gets a little way through the code in the DLL before failing, but I want to track down exactly where.
The technique of debugging a DLL is described here on MSDN. You'll need to do this from Visual Studio 6 (i.e. the tool that developed the DLL) and so the terminology will have changed. But the principles remain the same.
Attaching VS6 debugger on the .NET process shall work, as long you have the PDB file with the corresponding binary and the sources. You can break only on DLL code, however.
Attaching another VS+ shall work if the flag "Allow unmanaged debugging" is checked, but there is a possibility that symbols are not loaded by the debugger. A recompilation of the DLL shall solve the last problem.
Open Visual C++ Dll project, set breakpoint where you need. In the Project properties, Debug, Executable for debug session, type .NET executable file which uses this Dll. Start debugging (Go). When VC++ function is called, debugger breaks. Using this way, you can debug only unmanaged VC++ code.
Another way is to start debugging from .NET client in mixed debugging mode. Add VC++ project to the solution and rebuild it to debug both managed and unmanaged code.
I just migrated to Windows Ultimate 64 SP1, because my system's hard drive crashed. I installed Visual Studio 2005 SP1 and all the patches that Microsoft has recommended. I finally got my source code from my SCM, but now debugging does not stop on any of my breakpoints I have set. This is just a plain Winforms app, nothing fancy.
The first thing I did was to change the build target to x86. No dice. Then I went and downloaded Debugging Tools for x64, still no dice. I set the debugger to break on all exceptions both handled and unhandled. No dice either.
I've been looking at Google search results, but no luck there either. I've been at this for 3 days now with no luck. Has anybody dealt with this issue before?
Update:
The projects are all set to Debug (x86).
Breakpoints stay normal when the debugging session starts.
I already did a re-install, and that didn't work either.
I am running as Administrator and turned off UAC.
I attached to the project using "Attach to Process", and I was able to step into the code that way. I'm hoping to find out why it is not auto attaching, in order to avoid having to do this manually every time.
This is listed as a known issue for VS2005 on Vista (Via MSDN):
Title: Just-In-Time (JIT) Debugging of
an elevated process will fail
Description: Elevated processes cannot
be JIT Debugged by VS 2005. This
includes system processes, such as
IIS, and applications started by
selecting ‘Run as administrator’.
Workaround: The debugger must be
attached manually before the debugger
will catch unhandled exceptions or
user break points
(System.Diagnostics.Debugger.Break,
__debugbreak, etc).
Couple of questions.
When your code fires up, does the breakpoint become an empty circle with a tooltip that indicates that the breakpoint won't be hit? Or does it become a full circle with a tooltip that indicates the process it's attached to?
You can try manually attaching the debugger to see if you get any traction that way. Just fire up the app and once it's running, go to the debug menu and choose "Attach to Process" - select the process that your app is running in and click "Attach".
I run Vista64 w/o issues - VS2008, though.
I am using Visual Studio 2005 with the same patch level on both Windows Server 2008 x64 and Vista x64 SP1 without any issues.
Are you running it as admin? When all else fails, try uninstalling and reinstalling.
Insure that the project is set for a debug compile and not a release compile, as the release compile doesn't contain your debug information.