I have a C# Service that is calling a C DLL that was originally written in VC6.
There is a bug in the DLL which I am trying to inspect.
After having a nightmare trying to get debug to work I eventually added the dll to the VS2005 solution containing the C# Service and added the necessary _CRT_SECURE_NO_WARNINGS.
The debug version of the service is registered using 'installutil.exe' tool.
I can get the debugger to break just before the line where the dll is entered via a call to System.Diagnostics.Debugger.Break();.
I found some instruction on the net regarding stepping into debugging unmanaged code, and enabled the 'Enable unmanaged code debugging' check box, I've also tried turning on the Options->Debugging->Native 'Load DLL exports' and 'Enable RPC Debugging' (even though it's not COM). I've also copied the debug dll and .pdb to the same bin directory as the service.
However the unmanaged code is not being stepped into which is what I really need.
UPDATE: I found the Debugging Type in the DLL properties and set it to 'Mixed' as per suggestion on several sites but to no avail.
UPDATE2: My project now emits the debug dll and the pdb to the same directory as the debug service. Still unable to debug the dll.
Try setting the unmanaged code as the startup project. I know it doesn't make sense but I remember this working for a very similar project.
Since the DLL doesn't have an associated executable, when you try to run it will pop up asking what app to run. Browse to your C# app and then you should be good to go.
Happy debugging!
EDIT: it's been a while, but I think the debugging type Mixed is correct
In the end I created a console app and recreated all the prior calls just to make sure the call would act as it did in the actual service with the actual parameters once it got there.
I chronicled my fix and the resultant code at my site.
There is a workaround in Visual Studio 2013. Run the application from cmd line. When System.Diagnostics.Debugger.Break(); is hit, a Visual Studio Just-In-Time Debugger window should pop out. Check "Manually choose the debugging engines.", click "Yes" and ensure that "Native" engine is checked. Click "OK". Now you should be able to step into the native code as if you would by running the code from within VS.
Related
So i have an open source project to which i made changes to and produced a dll.
Next i used that dll in a project of mine.
However there are some problems in the changes i made so i wanted to apply some breakpoints to my code in dll so i can check some variable values.
Is it possible to apply breakpoints in DLL and then when my program uses that dll for function calls, the breakpoints in the dll source that i put gets activated gets activated.
I have searched the internet and it is really confusing and since i am new i really have no idea on how to proceed.
I just wanted to breakpoint activated that i have inserted in the source.
I would add both projects together in a solution and make a project reference to the open source project from your project. Once this is complete you can set a break point where ever in the open source project and it will break just like your project. Just make sure everything is in debug mode.
You debug a process. Either start your program with the debugger, or attach it afterwards. Then set breakpoints on the code or functions within your DLL.
Some debuggers will let you add breakpoints on a module before it is loaded (say your DLL is loaded later in the process execution).
I've really been banging my head against the proverbial wall over this one.
I have a solution which contains both C# and C++ code projects.
I often call the C++ DLLs, which are compiled in this project from the C# via P/Invoke. No problemo. All the requisite debugger settings through the *.sln file, as well as the C++ and C# files, have been properly set, to the best of my knowledge. Note: I often am able to debug similarly P/Invoked C++ code with no issues!
Naturally, I figured that, perhaps, the symbols weren't loading -- yet, upon opening the modules window, I discovered that the DLL into which I am attempting to step isn't even listed! Running the function in my C# program does indeed use the DLL (I get the correct output), but, whilst watching the Modules window, the DLL still does not appear.
Does anyone have an idea of what's going on?
tl;dr --> I have a fair amount of experience with debugging P/Invoked C++. However, the DLL I wish to debug does not even appear in the Modules list (so I obviously am not able to step into it if the VS debugger appears to be completely unaware of its existence).
Thanks in advance!!
Cheers!
-Kadaj
My guess would be that you do not have debugging turned on for unmanaged code. Go to the Start-up project's Properties->Debug tab. Check "Enable unmanaged code debugging".
How do I debug a native code project from inside a managed code project? I am using C# to call C++ code and need to debug the C++ code. Otherwise, I must exit out of the project, open the C++ project, create a tester and then debug the code. This is horrible.
Add your c++ project to the solution containing your C# code
In the C# project properties pages, under the debug tab
Check "Enable unmanaged code debugging"
If that doesn't work you also need to open the Options dialog from either the Debug or the Tools menu (in VS2017) and go to Debugging->General. Check the option
"Suppress JIT optimization on module load (Managed only)."
You will then be able to debug into your C++/CLI and C++ code. (This final tip comes from Kim Togo Andersen.)
In the debugging options for visual studio you HAVE to specify the correct debugger type.
Open up the property dialog window for the project, and under the Configuration Properties select Debugging. For the Debugger Type option, select the property that applies:
This can be auto, or mixed. I prefer mixed as it is explicitly stating you want both managed and native debugging.
As a side note, you can pick native only, but you won't be able to set a breakpoint in managed code. I'm not sure if this is an issue for you or not.
If you pick managed only, you obviously won't hit any breakpoints in native code.
I have a VB6 object that is wrapped by a .NET class. As far as I recall it is possible to step through a VB6 object by simply running the VB6 library and inserting a breakpoint at the desired location.
However this does not appear to be working in my case. I have attempted to recompile the VB6 object and re-reference it in my .NET project but this doesn't appear to have helped.
Where do I go from here? Is there a way to insert Debugger.Launch() equivalent into a VB6 project? Any help would be appreciated!!
Lifted from robgruen's blog:
If you are using interop to call into a VB6 ActiveX dll or exe and you
need to debug your VB6 project you may find yourself having both
VS.NET and the VB6 IDE open. This can certainly be far from
efficient.
Typically you set your VB6 project to “Wait for the Component to be
created” and you launch your .NET app and then hit breakpoints within
the VB6 component. Well, there’s an easier way to do this. You can
actually debug your VB6 component within VS.NET. Here’s what you need
to do:
1) Build your VB6 project with symbols.In VB6 open up your vbp file
and goto “Project->Properties.” Select the “compile” tab and check
“Compile to Native Code.” Then select the “No Optimization” radio
button and check “Create Symbolic Debug Info.”
This will generate a .PDB (Program Database) file along with your
.EXE. This file contains the debugging information so the VS.NET
debugger can line up source and hit breakpoints, etc. (Make sure you
have binary compatibility on your VB6 dll set or you’ll have to drop
and re-add your reference to the VB6 component in VS.NET.)
2) Open your .NET project in VS.NET.
3) Go to the project properties and select the “Configuration
Properties->Debugging” property page and enable unmanaged debugging.
For VB.NET projects this option is “Unmanaged code debugging” and for
C# is “enable unmanaged debugging.”
4) Select the property page for the solution.
5) Add to the “Debug Source Files” an entry that points to the path
where the source code is for the VB6 component.
6) Add to the “Debug Symbols Files” an entry that points to the folder
where the .PDB file is that was generated in step 1.
7) You should now be able to open your .bas, .cls, .frm, etc. files in
VS.NET and you can put breakpoints in the file. Once you debug the
debugger will stop on those lines of code.
I have a Visual Studio solution with four C# projects in it. I want to step into the code of a supporting project in the solution from my main project, but when I use the "Step into" key, it just skips over the call into that other project. I've set breakpoints in the supporting project, and they're ignored, and I can't for the life of me get it to step into any references to that project.
Everything is set to compile as "Debug", and I've seen Visual Studio warn me that my breakpoints won't be hit before - it doesn't do that in this case. It's as though it looks as though my code will debug, but then at run-time, there's a setting somewhere that tells Visual Studio not to step through the code in that project. All the other projects in my solutions debug without problems.
What box have I checked to cause this behavior?
UPDATE FOR CLARITY: The "Just my code" option is currently disabled. Also, since the code belongs to a project in my same solution, I don't think the "Just my code" option applies here. I thought it only applied to pre-compiled code that I didn't have the source for, but since I have the source in my project, I don't think this option has any effect.
Not sure if this is it, but "Tools>Options>Debugging>General:Enable Just My Code" is a possibility. (I prefer to always leave this unchecked.)
It turns out that the assembly needed to be copied into the GAC before it could be debugged. Under the debugging option "Just my code", there's an option to suppress an error if you don't have any user code, and it was suppressing the following error:
The Following mobile was built either
with optimizations enabled or without
debug information. (Module name and
path) To debug this module, change its
build configuration to Debug mode.
Since I was building it in Debug configuration, I searched on that error message and got this:
http://claytonj.wordpress.com/2008/01/04/the-following-module-was-built-either-with-optimizations-enabled-or-without-debug-information/
Problem solved. I don't know why it needs to be in the GAC in order for me to step into the project, but it does. I don't ask why, I just ask how, and then I do it...
One thing to check for is that your supporting project assembly has not been installed in the GAC. Open a command prompt and run the following to make sure...
gacutil /l assemblyName
You need to ensure the supporting projects have pdb files or else Visual Studio will not have the necessary information to step through the code.
If you have the source code for the dll's into which you are trying to step into, do the following:
Click on the project in which these dll's are added as reference and remove them.
Add the Project(s) corresponding to the dll(s) to the solution
Right click on the project -> Add Reference -> Choose the newly added Project(s).
Now set the break point and debug the code.. You will be able to step into the code.
The reason for the issue is because you program is still referencing the old dll (without the source code) as it has been added to your project as a reference. Once you remove that dll and add the Project (Source code of the dll) of the dll, Visual studio will be able to step into your code.
A couple of possibilities:
There is a check box to step into "just my code". Its intent is to make it so you can't step into Microsoft's Framework code (unless you choose to by unchecking the box).
You might try recompiling the supporting code to make sure the code you're debugging exactly matches the code file you're looking at. VS does care about this and will disable a breakpoint if you put it in the code file whose version doesn't match. Also, make sure the PDB file is in the same directory as the DLL.
In Visual Studio 2013 one way to cause this behaviour is to set build configuration to Release.
Put it back to Debug and see if that helps.