I create a project,and I set "DLL" mode on output. I want debug my dll project , so I do "attach to process",(at the beginning ,I can not find "attach to process",but after I install the "GUN debugger plugin monodevelop",I can find it in the RUN menu.)
I debug a DLL project which has already attached to a process, but it always stop at the Line: "b7799424 pop %ebp" in the "Disassemly+"file.
Application output shows:"0Xb7799424in__kernel_vsyscall()".
I can not debug the DLL program.
Anyone can give me some help to this trouble.
Demi
The method of debugging the DLL (or library) project in Monodevelop IDE :
Instead of attaching to the exe that references your dll have MonoDevelop launch the exe for you. The trick to getting MonoDevelop to launch the exe for you is like this :
Create an empty solution.
Add your .exe project to this solution.
Continue to add your .dll project to the solution.
Set that your .exe project as the startup project.
Set the output path of your dll project in the debug file of your .exe project .
Build the entire solution and select Debug from the Run menu.
The MonoDevelop will launch your exe in the debugger and should be able to break at breakpoints within your dll project.
This methode is referenced by this webpage.I tried this method and it can work.
Hope this can help other people.
Demi
It looks like you are using the GDB debugger which is pretty low level, maybe you should try with the soft or hard debugger, instructions are found on the monodevelop website
Related
I have a VB6 application that runs dependent on a DLL, to which both of them I hold the source code and are in separate vbp projects.
I know how to use breakpoint and run VB6 debug mode in the application project, but I want to know if it is possible to run debug mode for the DLL?
I saw this article http://www.ni.com/tutorial/4071/en/. Does it mean I first have to compile the application, then in the DLL project I start debug mode by invoking the compiled application and hook it to use the DLL from the project? what does the "TestStand" in the article mean?
Open one of those 2 projects and add another (File - Add Project...) and then set your
application project as start up (project explorer, right click on application project).
I have a C++ DLL project in Visual Studio I've downloaded, which is a plugin module for another existing program (a media Player). The DLL created by this project is saved into the addon folder, is loaded by the media player and works great with no issues. However, I would like to be able to step through the code in the library while the player is running to understand how the code works.
The problem is that when I setup the project to launch the media player and step through the DLL project code, it starts fine and I can set breakpoints. But at certain times, the Visual Studio debugger tries to access other loaded DLLs inside the media player, which I don't have source code for, and it crashes the whole thing with an "access violation writing location blah blah blah" error. I have no interest in trying to access any other libraries the program is loading other than the one I have the source code for, so is there any way to prevent the Visual Studio Debugger from trying to hook into these other libraries? I know the error is not due to anything in the DLL project itself because it runs absolutely fine if I just tell it to "Start Without Debugging."
I have the source code for, so is there any way to prevent the Visual
Studio Debugger from trying to hook into these other libraries?
Please try these steps:
Suggestion
1) check Enable Just My Code under Tools-->Options-->Debugging-->General
2) enter Tools-->Options-->Debugging-->Symbols-->choose All modules, unless excluded and then click Specify excluded modules
then input the name of the dlls you want to exclude. Their symbols will not be loaded when you debug your application.
3) do not forget to uncheck option Warn if no user code on launch(managed only) under Tools-->Options-->Debugging-->General
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
One of the awesome things I remember in Visual Basic 6 from years ago that you could just load up an ActiveX exe project into the IDE, set a breakpoint, press Run and whenever someone (either an EXE or a project in a different IDE) called that DLL, your breakpoint would hit.
Is something like this possible with Visual Studio 2008? Can I load up a WinForms project into one IDE and a Class Library project into another IDE and have the WinForms project call the Class Library project?
In VS you cannot attach two debuggers to the same process (it is possible to attach VS and WinDbg to the same process, but not in the default manner).
Point is, you don't have to use two debuggers or include the auxiliary project in your solution. Immediately after the dll load you'd be able to step through it and set breakpoints in it as if this was the solution you just compiled - all you need is the dll's debug symbols (pdb). Typically the dll load time is at process launch - but if it is loaded dynamically you might want to break immediately after the LoadLibrary call and only then set breakpoints in the dll. You can set the breakpoints in advance, but you'd still have to break somewhere after the dll load to enable the breakpoints to be translated into instruction addresses.
[Edit:] This does (I hope) answer the question as you put it, but it would not reproduce the VB experience you describe. AFAIK there is no way to set breakpoints in a library that would be applied to every process that loads that library. The closest I can think of is for you to set a MessageBox displaying the process ID in the library initialization routine (essentially DllMain), then manually attach a debugger to that process and set breakpoints as desired.
You can:
1) Add the project with the DLL to the solution with the EXE (this not quite what you're asking).
2) You can attach the IDE with the DLL project to the process running the EXE from Debug -> Attach to process. I never tried to attach two debuggers to the same process at the same time though.
I have a project(A) that references an assembly from an external project(B) class library that is located in another vs solution.
I have yet to understand how i can efficiently debug the class library from B while running the program from project A. Is there something I have to enable on project B such as debug info etc so I can step-into at debug time from A?
Try disabling Just My Code (JMC).
Tools > Options > Debugging
Uncheck "Enable Just My Code"
By default the debugger tries to restrict the view of the world to code that is only contained within your solution. This is really heplful at times but when you want to debug code which is not in your solution (as is your situation) you need to disable JMC in order to see it. Otherwise the code will be treated as external and largely hidden from your view.
EDIT
When you're broken in your code try the following.
Debug > Windows > Modules
Find the DLL for the project you are interested in
Right Click > Load Symbols > Select the Path to the .PDB for your other project
Assume the path of
Project A
C:\Projects\ProjectA
Project B
C:\Projects\ProjectB
and the dll of ProjectB is in
C:\Projects\ProjectB\bin\Debug\
To debug into ProjectB from ProjectA, do the following
Copy B's dll with dll's .PDB to the ProjectA's compiling directory.
Now debug ProjectA. When code reaches the part where you need to call dll's method or events etc while debugging, press F11 to step into the dll's code.
NOTE : DO NOT MISS TO COPY THE .PDB FILE
This has bugged me for some time. What I usually end up doing is rebuilding my external library using debug mode, then copy both .dll and the .pdb file to the bin of my website. This allows me to step into the libarary code.
I run two instances of visual studio--one for the external dll and one for the main application.
In the project properties of the external dll, set the following:
Build Events:
copy /y "$(TargetDir)$(TargetName).dll" "C:\<path-to-main> \bin\$(ConfigurationName)\$(TargetName).dll"
copy /y "$(TargetDir)$(TargetName).pdb" "C:\<path-to-main> \bin\$(ConfigurationName)\$(TargetName).pdb"
Debug:
Start external program: C:\<path-to-main>\bin\debug\<AppName>.exe
Working Directory C:\<path-to-main>\bin\debug
This way, whenever I build the external dll, it gets updated in the main application's directory. If I hit debug from the external dll's project--the main application runs, but the debugger only hits breakpoints in the external dll. If I hit debug from the main project, the main application runs with the most recently built external dll, but now the debugger only hits breakpoints in the main project.
I realize one debugger will do the job for both, but I find it easier to keep the two straight this way.
If you have main (project A) and external library (project B):
Open (project A) solution in Visual Studio.
Right click on solution -> Add Existing Project -> then select the .csproj file of your external library (project B).
Again in visual studio right click on (project A) -> Add -> Project Refference... -> and then add checkmark on your external library which you want to debug (project B).
Finally place brake-points in (project A) where your external library (project B) is called and run with F5.
[according to Martin Beckett, the guy who send me this answer ]
You can debug into an external library.
In the project settings tab look for 'visual studio directories' in the 'source code' field include the path to the openCV sources. Then make sure that the .pdb files for each of the debug dll are in the same directory as the dll.
NuGet references
Assume the
-Project_A (produces project_a.dll)
-Project_B (produces project_b.dll)
and Project_B references to Project_A by NuGet packages then
just copy project_a.dll , project_a.pdb to the folder Project_B/Packages.
In effect that should be copied to the /bin.
Now debug Project_A. When code reaches the part where you need to call dll's method or events etc while debugging, press F11 to step into the dll's code.
I was having a similar issue as my breakpoints in project(B) were not being hit. My solution was to rebuild project(B) then debug project(A) as the dlls needed to be updated.
Visual studio should allow you to debug into an external library.
The quickest way to do this on a one-off basis is to open the Proj B file directly in the Visual Studio instance in which you are editing and launching Project A (File => Open => File). You don't need to add the file to the solution. Just having it open in the editor will let you create your breakpoints directly in the Project B file.