I build a "hello World" kind of app-dll combination in C# and set the break point
System.Diagnostics.Debugger.Break() in the DLL and it breaks promptly no issues.
I have another exe and DLL combination for which I have the source code for the DLL only. In this new DLL source code I insert System.Diagnostics.Debugger.Break() build the Debug version of the DLL but when it runs in a PowerShell it does NOT break. Why is it not breaking? Further System.Console.WriteLine() works in my sample DLL but not in the real DLL.
I checked the csproj file hoping to find a setting like Break on BreakPoint: NO or Screen Print: NO or something to that affect no luck.
I was loading the DLL inside a PowerShell and then running it and hoping it to freeze up or show some sing of failure. Then after much Googling I realized PS was preventing the break and the display. So the solution is, run WinDbg and open powershell.exe (Open executables). That will open a new PS and in that environment my DLL does break and does display the Console Writes.
Related
Okay, I've been struggling with this for full last couple of hours. I have a Windows 7 32-bit installation, on which I'm trying to compile some old code. I do not have any working knowledge of VB, but I'm trying to build a VB6 project which is part of the code base. The code compiles and when I run it after full-compile, it runs. But I can't seem to find where this file is. Task manager shows VB6 as process. It is not present in %TEMP%, and not in my project directory. Running an exhaustive search on my single drive configuration, I can find only one entry by this name, and this file has a timestamp older than current time. I attempted delete on this one while the debugger was still on breakpoint and it succeeded. As last resort in prefetch directory, I deleted that entry also, but magically this file still runs when on VB6. What must have been going on?
When you run an application within the VB6 IDE, it entirely runs within the VB6 IDE. Unlike some other languages, it isn't creating an executable file and then running it separately while hooking a debugger up, it just starts running your code using the VB interpreter.
To create a standalone .exe file, you need to create it separately. In the "File" menu, choose "Make projectname.exe". For full details, see "Making and Running an Executable File" in the Visual Basic 6 Concepts guide.
First and foremost, I'm an absolute newbie at debugging compiled code (until recently, I didn't even know it was possible!). I've successfully used the VC6 IDE to attach to a process but I can't get WinDbg to work...
The problem is that I have a VB6 service that I need to debug in a production server. I really don't understand much of how the .EXE is compiled because it is generated by an external tool called "NT Service Toolkit". The code I have is compiled into an ActiveX DLL that is used by this .EXE.
I've done everything I found on the internet to make the service debuggable with the VC6 IDE: compile without optimizations and generate symbols. When I use the VC6 IDE to attach to it, it works as expected... I can set breakpoints and everything works fine except for the annoying bug that kills the service when the debugging session stops.
When I try to use WinDbg however, I cannot set breakpoints; it fails with an error:
Unable to insert breakpoint 0 at 00000000`0046f715, Win32 error 0n299
"Only part of a ReadProcessMemory or WriteProcessMemory request was completed."
bp0 at 00000000`0046f715 failed
WaitForEvent failed
I've already downloaded symbols for windows' components from the symbol servers, as instructed in the documentation I could find, and I also included the PDB file for my service in the symbols folder...
One thing I noted is that I can get symbolic information when I check the "Noninvasive" box when selecting the process to attach to because I see things like wow64win!ZwUserGetMessage instead of just the address`offset syntax... but when I do, I also get this warning:
WARNING: Process <PID> is not attached as a debuggee
The process can be examined but debug events will not be received
In this case, I can set breakpoints, but when I try to run the service, it fails with:
0:000> g
^ No runnable debuggees error in 'g'
UPDATE
When I set a breakpoint in "Noninvasive" mode, detach, and reattach with "Noninvasive" un-checked, the breakpoints I set while in "Noninvasive" mode remain, and are hit successfully, but I can't set new breakpoints unless I repeat the whole process (detach, attach in "Noninvasive" mode and reattach). Does this make sense? What could I be doing wrong?
I found the problem. It was a conflict in the module names.
When WinDbg loads the modules for a process, it names them as the file where they live, just WITHOUT extension. Therefore, if, as in my case, two modules that must be loaded share the same name, say MyService.exe and MyService.dll, there will be two modules named MyService; in this case, WinDbg breaks the ambiguity by appending _<start-address> to the name, resulting in, for example:
...
MyService
MyService_11000000
...
(The following is a rationalization of what happened, since like I said, I'm pretty new to "attach to process"-type debugging and I lack knowledge of WinDbg internals...)
My problem was that the PDB file for the DLL (MyService.pdb), which was the module I was interested in debugging, was being matched to the EXE file's module (MyService), so the DLL's symbols were not loaded before trying to "restore" the breakpoints, resulting in the Win32 error 0n299 I was seeing earlier... It appears that the g command also tries to "set" the saved breakpoints, and since the symbols were not yet loaded, it would not let me start the thing after the default breakpoint either...
...
Or something like that... Obviously, if someone has a more accurate explanation, I'd very much like to be enlightened. :)
For the moment, I just changed the service EXE's name, and now everything works fine.
We have a DLL which provides the data layer for several of our projects. Typically when debugging or adding a new feature to this library, I could run one of the projects and Step Into the function call and continue debugging code in the DLL project. For some reason, that is no longer working since we switched to Visual Studio 2008... It just treats the code from the other project as a DLL it has no visibility into, and reports an exception from whatever line it crashes on.
I can work around that by just testing in the DLL's project itself, but I'd really like to be able to step in and see how things are working with the "real" code like I used to be able to do.
Any thoughts on what might have happened?
Is the pdb file for the dll in the same directory as the dll? This should all work -- I do just this on a regular basis. Look in the Modules window which will show you whether it's managed to load symbols for the dll. If it hasn't then you won't be able to step into functions in that dll.
It sounds like you have "Just My Code" enabled and VS is considering the other projects to not be your code. Try the following
Tools -> Options -> Debugger
Uncheck "Just my Code"
Try again
I've gotten around this issue by opening a class that will be called in the project you need, placing a breakpoint, keep the file open, and run the debugger. The debugger will hit the breakpoint and the relative path that VS uses will be updated so that future classes will be opened automagically.
Summary
I want to alter the build process of a 2-assembly solution, such that a call to ILMerge is invoked, and the build results in a single assembly. Further I would like to be able to debug into the resultant assembly.
Preparation - A simple example
New Solution - ClassLibrary1
Create a static function 'GetMessage' in Class1 which returns the string "Hello world"
Create new console app which references the ClassLibrary.
Output GetMessage from main() via the console.
You now have a 2 assembly app which outputs "Hello World" to the console.
So what next..?
I would like to alter the Console app build process, to include a post build step which uses ILMerge, to merge the ClassLibrary assembly into the Console assembly
After this step I should be able to:
Run the Console app directly with no ClassLibrary1.dll present
Run the Console app via F5 (or F11) in VS and be able to debug into each of the 2 projects.
Limited Success
I read this blogpost and managed to achieve the merge I was after with a post-build command of...
"$(ProjectDir)ILMerge.bat" "$(TargetDir)" $(ProjectName)
...and an ILMerge.bat file which read...
CD %1
Copy %2.exe temp.exe
ILMerge.exe /out:%2.exe temp.exe ClassLibrary1.dll
Del temp.exe
Del ClassLibrary1.*
This works fairly well, and does in fact produce an exe which runs outside the VS environment as required. However it does not appear to produce symbols (.pdb file) which VS is able to use in order to debug into the code.
I think this is the last piece of the puzzle.
Does anyone know how I can make this work?
FWIW I am running VS2010 on an x64 Win7 x64 machine.
Update: Why do I want to do this?
It's been asked: 'Do I really need to ILMerge during the debug scenario?'
The assemblies of my solution will need to coexist in the same folder as those of other solutions (some of which I will likely develop)
Some of these solutions will share dependencies on different versions of some assemblies.
So Solution1 might be made up of Console1 and ClassLibrary1.dll(v1) and Solution2 might be made up of Console2 and Classlibrary1.dll(v2).
Rather than register everything in the GAC, I thought I could ILMerge the correct version of a dependency into the primary assembly of the solution to avoid a collision.
However this currently renders it impossible to debug the solution, which I need to do in place in conjunction with the other solutions which will be present.
Does this sound complicated? That's because it is.. :D
I'm sorry you're having problems. I didn't follow your exact steps, but I created a console application, A.exe, that called a method in a dll, B.dll. I built both assemblies in Debug mode (so that they had PDB files). I then merged them like this:
ilmerge /out:foo.exe A.exe B.dll
(Actually A and B were in another directory so my command line was a little more complicated, but that shouldn't make a difference.) After ILMerge completed, there were two files in the current directory: foo.exe and foo.pdb. I then typed:
devenv foo.exe
This opened up Visual Studio and then I hit "F10" to start the debugger. I was able to step into the Main method in the executable and then used "F11" to step into the method in that had originally been in B.dll. The debugging experience was just the same as it had been in the original Visual Studio solution with the two assemblies.
If you are still having problems, please feel free to put your entire solution into a zip file and send it to me (mbarnett at microsoft dot com) and I can try it out.
I would suggest that you only ILMerge release builds of your assemblies. I can't imagine any benefit you'd get from merging debug assemblies.
I tried to do something like this and found that you should not rename anything, neither before not after the merge. Moving stuff to to separate directory is fine. If you do not rename anything, it works.
If you are still using ILMerge, like I am, there is also an another solution to debugging issues. At least for me the dubugging started working after NOT using the portable PDB format. My project is .NET Standard 2.0 and I was running it under .NET Framework.
I don't think ILMerge can do it. OTOH smartassembly from red-gate (not free) can do it, at least so it says at features
And yes, I do agree with Mike to only use ILMerge for release versions.
I have an executable (compiled by someone else) that is hitting an assertion near my code. I work on the code in Visual C++ 2003, but I don't have a project file for this particular executable (the code is used to build many different tools). Is it possible to launch the binary in Visual C++'s debugger and just tell it where the sources are? I've done this before in GDB, so I know it ought to be possible.
Without the PDB symbols for that application you're going to have a tough time making heads or tails of what is going on and where. I think any source code information is going to be only in that PDB file that was created when whoever built that application.
This is assuming that the PDB file was EVER created for this application - which is not the default configuration for release mode VC++ projects I think. Since you're asserting, I guessing this is a debug configuration?
Short of any other answers, I would try attaching to the executable process in Visual Studio, setting a break point in your code and when you step into the process you don't have source to, it should ask for a source file.
Yes, it's possible. Just set up an empty project and specify the desired .exe file as debug target. I don't remember exactly how, but I know it's doable, because I used to set winamp.exe as debug target when I developed plug-ins for Winamp.
Since you don't have the source file it will only show the assembly code, but that might still be useful as you can also inspect memory, registers, etc.
Update
If you are debugging an assertion in your own program you should be able to see the source just fine, since the path to the source file is stored in the executable when you compile it with debug information.