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.)
Related
I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping
Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).
I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps
I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments
exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.
For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.
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.
I'm working on a project that retrieves a number of Solutions from a team foundation server, to a temporary folder, uses Microsoft.Build.Execution.BuildManager.Build to build a release version for these Solutions, and cleans up the temporary folder with source code afterwards.
The problem arises when running my project with a debugger attached:
during the clean-up I get a system.UnauthorizedAccessException with message
"Access to the path ...\obj\release\CalithaLibrary.pdb denied".
Using sysinternals Process Explorer I found out that the lock was aquired by devenv.exe.
When I build a release version of my project and run it outside of visual studio the problem does not arise.
Any ideas as to why Visual Studio would aquire a lock of a PDB belonging to a project that was never opened by Visual Studio?
Edit: The first answer I received made me think I probably wasn't clear enough about the situation:
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
If I were trying to delete the AutoReleaseService.pdb from my own project, to which I did, in fact, attach the debugger, I'd understand, but the project to which the pdb file that gets locked belongs hasn't even been run on my machine, let alone debugged. I only built the project.
I'm debugging a project named "AutoReleaseService.exe" which uses Microsoft.Build.Execution.Buildmanager to build (but not run or debug!) a number of other projects, among which CalithaLibrary.
Well, CalithaLibrary looks like a DLL project, which is most certainly being used when you run AutoReleaseService.exe. It is straightforward - when the exe project is run, it uses all of the dll-s which it depends on. Visual Studio (devenv.exe) locks the .pdb files, because they are the link between the source code and the executable when you debug the application, and if you open the executable from outside of Visual Studio - they are not locked, because you do not need them then.
I'm starting to become pretty sure there's a bug in MSBuild here somewhere.
Luckily I managed to debug the last part of the application I needed to debug by excluding a few of the builds it was making, so it's now running in Release and does not encounter problems anymore.
Some information on why I think it must be a bug.
My application's workflow was something like this:
Create a temporary workspace on Team Foundation Server
GET a number of solutions/projects from TFS to a temporary folder
BUILD a number of these (configurable through xml but that's beside the point) to a different temporary folder
Clean up the temporary folder with source code
I tried setting MSBuild Options "DebugType" to none and "DebugSymbols" to false, but for some reason it kept outputting the Program Database files which is why I think there's a bug somewhere.
Whenever I skipped the "Building" step and skipped straight ahead to "Clean up" there were no locks on any files.
I'm updating an old mobile device application for better flexibility. I had basically added the ability to configure the address of our SQL server in the case that we want to use our test server as opposed to our production server. I don't think this is causing the problem, but I wanted to state it. I also upgraded the project from a VS 2003 project to a VS 2005 project.
The issue I am having is that when I try to run the program in the VS emulator for Pocket PC, I get an error. It occurs after our "main menu" form loads and the user selects the next form to load. The form is initialized without issue, but when we try to run the .ShowDialog() method, it throws a System.MissingMethodException.
I don't have a lot of experience with the Compact Framework and really have no idea where to start looking for problems. I stepped the debugger through the entire initializing process for the new form and it ran without issue. But, again, when we come to the ShowDialog call, it throws the error.
Any ideas in where to start looking or known issues would be greatly appreciated.
I'm usually getting MissingMethodException for this reason:
I've got at least two files in my project, for instance an .exe file and a .dll file
I make changes to the .dll file's source code, and recompile
VS says it deploys the new .dll file to the device, but indeed it does not (it keeps the old file)
The .exe starts up fine, but when it starts accessing the .dll file the application throws a MissingMethodException, because it can't find the methods in the old dll file.
Fix: Delete the entire application directory from the device and redeploy.
I should have added this long ago. The answer ended up being that the incorrect version of .NET was installed on the Mobile Device.
A possible issue that can cause this situation is that the DLL is not being updated when deployed. It can be caused by the DLL in question being a dependency for more than one executable.
For example let's say executable A is running on the device and it is dependent on the DLL's method callA. You are trying to debug executable B which is also dependent on the DLL but on the method callB that you just added. When Visual Studio goes to deploy the DLL with callB in it, it is unable to do so because executable A is still using it. Visual Studio does not tell you that it was not successful in deploying the DLL. (Liar VS! ;)
To fix it, kill all the executables that depend on the DLL and then deploy it.
#Felix Alcala - You got an up vote from me. I would add this as a comment to your fix because it is directly related. Alas, I did not have the rep to do so. But, I want this answer to be public because I found it helpful
Start looking in the ShowDialog method itself. The error is slightly misleading - it's not ShowDialog which it can't find, but the JIT compiler is probably trying to compile ShowDialog, and throwing that exception (because ShowDialog is trying to call something it can't find). If ShowDialog is in a different assembly, then there may be something static that can't be initialized, which could similarly cause this - but start out looking in ShowDialog itself.
Because of this, one trick to finding the problem (if it isn't obvisou) is to reduce the code in ShowDialog until you find the line causing the problem. I'd start out commenting ALL the code, to confirm my hypothesis. If you no longer get the exception, try uncommenting about half of the remaining code at a time, etc.
You can get this exception when you try to use a regular WinForm class from a compact project.
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?