I am using VS.NET to attach to a process, the process has a lot of DLL loaded, I built one of the DLL and try to set a breakpoint inside my DLL. I click "New Breakpoint" and type my function name Func_A and checked the "Use Intellisense to verify" box. Then I click OK but the VS.net complains that it can't find the function.
When the process is attached I checked the output of VS.NET, it didn't has a "can't load symbol" message behind my DLL line, so I think it has successfully located my PDB file. I don't know why I can't set the break point.
My project is C# managed project. Note that for all the DLLs, some has debug informations, some don't, but I believe VS.Net has identified my debug informations.
Please suggest other ways to try...
Another question is is there any tool to see the functions that can set breakpoint in an assembly DLL file?
If you see a lot of DLLs loaded then it is likely that you are running the debugger in native mode. It is an option in the Tools + Attach to Process dialog, be sure to pick Managed.
By far the easiest way to avoid trouble like this is to load the source code file and set the breakpoint by clicking in the left rail of the editor window. Also, don't use Attach to Process. Use Project + Properties, Debug tab, select "Start external program" and select the .exe that loads your assembly. You can now start debugging by simply pressing F5. Beware that this option is not available in the Express edition.
Could do with some more details really, but here goes...
Do you have the source for the DLL? If so, just open the code and add the breakpoint wherever you want.
If you don't, then you're pretty much relying on Intellisense which isn't always reliable I've found, particularly if managed C++ assemblies are involved. To help, you could look at the DLLs using Reflector to get the full namespaced function name and try that, ignoring Intellisense.
Using reflector will also let you see if the DLL is obfuscated (if 3rd party).
Hope this helps give you some new ideas of how to tackle it.
K
Related
I am currenlty trying to debug a service, but don't have the code located on the server, since there is alot and moving is not easy.
we are currently having issue with one server, and the only way I can debug the issue is by using dotpeek to decompile the .dlls and shown here #IgalTabachnik
Problem with this is the last step, my breakpoint gives an error and says that sourcecode is not availbale? which i don't get? ... it should be available through dotpeek?
Another things that might be an issue, is that I am debugging a schdule task, and I am not able to attach to a process while starting at the same time.
If you're having problems with dotPeek + symbol server, I do recommend using dnSpy. To do that you need to:
Open dnSpy as an administrator (dnspy-x86.exe or dnspy.exe depending on the target platform)
Load .exe file that contains the code of the service into dnSpy via File->Open
Navigate to the code where you want to put your breakpoint and set it there.
Go to Debug-Attach to process. Since you run dnSpy as an Administrator you should see your service on the list.
Select and attach to the process
Trigger the breakpoint.
debug
dnSpy generates it's own source code and has debugging capabilities so you can do everything in it. Its debugging experience is similar to Visual Studio's but it is not as reach as you can get in VS. Still, it can do its job.
Just as the title asks. I have solution with 5 projects in it. All dlls are connected with each other and whenever I start debugging, I can freely debug any of them. I'd like to add a separated project and access it's object by using reflection only (no references between the rest and 6th proj at all). Can I make it attach automatically to the debugger? I'm aware of function 'attach to existing process' but that's manual job.
You don't need anything special. Make sure you have pdb file next to the dll for that separate project, have source code locally matching to the version used to build that project, and possibly turn off "my code only" in tools -> options -> debug. At that point Visual Studio should pick up debugging information and allow you to set breakpoints and debug normally.
If PDB located somewhere else you can manually point to the PDP via debug->window->modules view by selecting "load symbols" from context menu on module you are interested to debug.
If sources don't match exactly you can instruct VS to use whatever you have also it likely will lead to confusing debugging experience (How does Visual Studio know if the source file matches the original version?).
You can put below line in your debugging dll ,in which function you want to debuge. it automatically ask you to attach with debugger
System.Diagnostics.Debugger.Launch();
I had to port a exe program to dll for usage with VFP, this is my first time learning about debugging process, i have checked a lot of documentation and threads here.
West-wind was a big help too (http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_ComplexObjects.asp)
The thing is, now i am doing all output debugging process via txt files, which is really annoying, so i tried to debug the dll directly, but i step into this error
Output Windows says
x86\Debug\dzg.dll: No native symbols in symbol file.
and in the IDE:
The Breakpoint will not currently be hit. No Symbols have been loaded for this document
I have tried to nuke, build, rebuild, sign and regasm /codebase, gacutil /i dzg.dll etc. (I checked all the exe were for .net 3.5)
also checked admin permissions on both vs2013, and vfp, command prompt when doing the registrations, etc
but i just can't load the symbol file to debug it
Have anybody done this before? most reports of "No Native Symbols" are for ASP or C++ but not with VFP
I really have tried all the solutions posted on this website, MSDN and other sites, but i really got into a dead end.
Any tips appreciated.
No native symbols in symbol file
That's accurate, the symbol file for a C# class library doesn't have any native symbols, only managed ones. This went wrong because you selected the wrong debugging engine in the Tools + Attach to Process dialog. Click the Select button and tick a managed debugger.
The much easier way to do this is by configuring the debugger in your C# project. Use the Project + Properties, Debug tab. Select the "Start external program" radio button and select the VFP executable. Now you can simply press F5 to start debugging.
I am not sure if i should mark Hans Passant comment as answer or not, but certainly i found a workaround.
if i open VFP manually and after then attach VS to it manually, i can debug the code on time and symbols and breakpoints will work fine, but if i start the debug process from VS2013 (by "Start External program" it will just not work
I'm loading a dll (c#) from QTP. Is it possible to debug the c# code when the qtp test starts.
Yes you can debug into the dll's you can, but you will need source (unless you want to look at the disassembly) and you will also need the PDBs (debug symbols) for the assembly. It is pretty easy to setup...
start the QTP application
start visual studio
open the source code and make sure the pdb's are in the same directory as the dll
in VS go to the debug menu and select attach to process
In the process list, select the QTP process and click "attach"
Set a breakpoint in the code
Start the tests that execute the code and if all is well you should hit the breakpoint
NOTE: if the breakpoint is not hit, VS probably can't find the PDB's and you either need to add a path in options in VS (or something so it can find them).
Also, try turning off "Enable just my code" in the Tools->Options->Debugging options page if it is still not working (mostly if you are looking at release built code).
Update: Answering comment... If you go to Tools->Options... Select "Debugging" on the list on the left and expand that, then select "Symbols" you can add paths there for VS to search for symbols. Also, if you don't have the exact symbols you can right-click the breakpoint and select location and check the option that will allow the symbols to be out of sync.
Hope this helps!
You can insert a call to Debugger.Break()and run the external application, when the break point will be reached Windows will offer you to debug the exception.
Choosing debug will enable you to run the code after the break inside Visual Studio and set break points inside your code.
In case you're using Vista/Win7 you might need to enable debugging - have a look at this post to learn how.
Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.
Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.
http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.
Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?
Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.
I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.
AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.
Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).
Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.
In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]
Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?
Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?