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).
Related
I'm working on a Xamarin project and when I make an instance of a certain class a bearkpoint inside the constructor never gets hit. Just after instancing the class i call for a function of that class and the Step Into functionality of visual studio 2012 sends me to another totally unrelated function of another class.
When I comment that unrelated function that the Step Into sends me to and call the function again, the Step Into sends me again to a totally unrelated function of another third class.
The functions don't even have the same name.
I already cleaned, rebuild, manuallly deleted bin and obj and nothing works.
Any one knows what is happening?
Note: the Go To Definition (F12) command works as expected but the Step Into (F11) doesn't. I also have it on Debug mode instead of Release.
Well the problem here is obviously your debug symbols are out of sync with your source files. A few ways this can happen:
you're not actively building debug symbols (thus relying on older leftovers), or have optimizations enabled. Note that simply having the debug configuration selected doesn't mean this is not the case -- "debug" is just a label, you can name it puppies for all VS cares. Check the settings.
it's possible there's conflicts with the GAC or the symbol server trying to download wrong symbols. Check your file names that they're not too similar to system DLLs.
You mentioned Xamarin -- I'd triple check that it has the right symbols. It's possible following the call stack through out of date Xamarin symbols is screwing up things when it comes out and back into your code (events).
Another thing I'd try is to cold start your executable, then attach through VS. Go line by line in the Output window and see which symbols are loaded, and equally important, which are failing to load. Check your output folder, check the .pdb file names. Make sure you're not confusing things with the .vshost.exe file, you only care about the executable and any DLLs of your own.
I am working on a solution that makes a $.get call to a controller (in a different solution in a different module) inside of a dll. How can I put a break point in the original code of the external project, and actually hit that break point?
Please explain this like you were explaining it to a six year old because im still pretty new to programming.
Make sure Visual Studio is attached to your server process. (if you hit F5, it will be)
Click Debug, Modules, and make sure symbols are loaded for the other DLL.
If they aren't, right-click it, Load Symbols
Open the original source file.
Set a breakpoint.
I am attempting to debug a class library in VS2013, however whenever I set a breakpoint in the library, it seems to be ignored when executing the code.
I am using a console project, which is located in the same solution to call the code of the class library. I've added the .dll, which has been generated by the class library, as a reference to the console project in order to connect the two projects.
How do I connect the two projects properly and stop VS2013 from ignoring the breakpoints?
Sounds like you need the PDB file(s) associated with the library's (DLL) files.
Without PDB files, it's possible to set a breakpoint on the library code, if you can see it, but the red breakpoint circle will say something like "Symbols could not be loaded...." and you won't land on any breakpoints.
So, if you can get the PDB files of the library, copy them to the bin folder of your project, add a reference to the library DLL, and hopefully that should make Visual Studio happy.
Also, when debugging the code in VS, if you go to Debug->Windows->Modules, that will open a new window in the IDE which shows loaded assemblies. That window will also tell you whether the symbols (PDB) have been loaded.
My solution had two class libraries, one application that needed them. Couldn't break anywhere in the class library code. All settings previously mentioned here were checked. I solved it by removing the class library dll from the references and then adding it back in as a reference. Voila. Previously ignored breakpoints in the class library became active.
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 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.