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.
Related
I am trying to debug my DLL Class Library on Windows, but I am not able to get the debugger to stop in the source code.
Environment: Windows 10 Pro x64, Visual Studio Premium 2013 Update 5. Project is a .NET 4.5 Class Library. The executable is actually instantiated by another .exe before it calls my .dll. (I don't have source access to either of these .exes.) The .dll is in the same dir as its calling .exe, but that is not the Class Library project directory. I know my .dll code is executing, as I create new windows in my code, which are opening.
I have tried Debug->Attach to Process... in VS2013, and I connect to the calling .exe process, but the breakpoint I have set in my code never is hit, despite that code definitely being called. What am I missing here?
EDIT: This is not a duplicate of another question:
Not getting any error message
Not intermittently working
The assembly is confirmed as being loaded and executed
Your assembly might be compiled for release or compiled without any debug info. If you do things correctly, you should be able to debug by attaching to process. Another thing that can be, your code executes before you can attach to it. sometimes, especially in services, you put thread.Sleep into code, so this buys you some time to attach.
The issue turned out to be VS was not correctly figuring out what type of code to debug. In the Attach to Process window, I had to switch from Automatic to manually specify debugging Managed (v4.5, v4.0) code type in the Attach to: option, before attaching to the parent .exe process. I could then step through my source. (As it turns out, copying the .pdb file was not required - VS still uses the version of that file in the original project Debug directory.)
I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.
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
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.