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 am trying to debug a windows service. It's running as a console application with Topshelf. The startup project runs fine in with breakpoints and everything but none of the referenced projects in the solution seem to load their symbols. All the .pdb files are in the respective bin-folders. And a copy of all the referenced .pdb files are also in the startup projects bin-folder. Everything builds/rebuilds when i press F5.
It worked fine a few days ago and still works fine on all my colleagues PC's.
I'm sure I'm running all projects in debug mode.
I've cleaned, rebuilt and tried attaching to the process instead of just F5.
I get the same behavior in both VS2017 and VS2015.
I've deleted all the source code and redownloaded and even reinstalled all versions of VS.
None of the referenced projects show up in the Modules window. (* Actually. One of the referenced projects does show up sometimes, but I don't understand when/why. I can debug that project - when it shows up in the Modules window)
Disable the debug option Enable Just My Code (Tools -> Options)
Be advised; turning this off will slow down start up time of the debugger since loads of symbols will be loaded. It's best to debug the other assemblies in their original solution.
You can also do this, Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All. That's it
I have a task of obfuscating my Xamarin Android project (let call it AndrProj) together with libraries it references: two PCL (let's call them PCL1 and PCL2) and Android library (AndrLib). PCL2 and AndrLib also have references to PCL1.
I was inspired by this article and decided to try Crypto Obfuscator For .Net v2015 demo version for my purposes.
I used its 'Visual Studio Project Integration Wizard'. PCL1 was set as 'First project' and AndrProj as 'Last project'. Only default settings were used for the beginning. Now when I build my project everything is perfect. Dll's in \bin\Release folder are obfuscated.
I would be completely happy if I could actually create an .apk file and try it on the Android device. But when I select Build -> Archive for Publishing in Xamarin Studio, after some time I see 'Build FAILED' and
Error occurred while obfuscation: - The assembly 'AndrLib' is
already obfuscated with Crypto Obfuscator. If you have run the Visual Studio Project Integration Wizard on your Visual Studio projects, you cannot obfuscate from the Crypto Obfuscator UI unless you first disable automatic obfuscation for this project from Crypto Obfuscator's 'Project' menu --> 'Enable/Disable Visual
Studio Integration' and Rebuild your solution in Visual Studio to
produce unobfuscated assemblies.
I also tried 'Export Android Package (.apk)' from Visual Studio 2013, but it gives less output and still does not create .apk.
I believe it complains only about AndrLib because it goes first alphabetically among PCL1, PCL2 and AndrLib. And more global problem is that creating .apk forces all assemblies to be obfuscated one more time. Is there any way to skip this second time obfuscation? Or to ignore this kind of problem?
Well, the solutions was pretty simple: I had to use MSBuild.exe directly with target SignAndroidPackage instead of creating .apk from IDE.
Here is an email from technical support regarding the described problem (may be useful for someone):
If your solution fails to build after doing MSBuild Integration, try the following:
Change the build output log verbosity as follows:
Visual Studio Tools menu --> Options --> Projects And Solutions --> Build and Run --> MSBuild Project Build Output Verbosity, set this to Detailed.
Now check the Visual Studio Output window for any hints or more information regarding the cause of the error.
Change the number of threads used by MSBuild to 1 as follows:
Visual Studio Tools menu --> Options --> Project And Solutions --> Build And Run --> Maximum number of parallel threads : set this to 1.
If you get an error message similar to "The assembly 'XYZ' is already obfuscated with Crypto Obfuscator..." when you Run (CTRL+F5) or Debug (F5) your solution, then try doing a Clean ( Visual Studio Build menu --> Clean menu item) and then do the Run (CTRL+F5) or Debug (F5).
Build failure can also occur if you ran the wizard multiple times, each time selecting a different "first" project. This problem usually presents itself via a "file not found" error in the build log/output. To solve this problem, start from clean non-integrated .csproj/.vbproj files (the wizard copies the original non-integrated project files to a .backup_%timestamp% extension before modifying the project files; alternately you can open the .csproj/.vbproj files in a text editor and remove the XML added by the wizard which can be found towards the end of the file). Then run the wizard again specifying the correct first and last projects.
I had problems Archiving and the problem went away after I downgraded Visual Studio 2017 Professional from 15.9.9 to 15.7.6.
I have a C# dll registered with regasm. This dll used with an older executable written in visual c++. I originally built the DLL in VS2008 on 32 bit xp. I recently moved it to Windows 8 and rebuilt it in VS2013.
I can no longer hit breakpoints in this dll. It worked just fine on the XP/2008 setup. The output directories are correct, the .pdb files are in the right locations, the setup is the same as it was before.
The only difference is that to get this to work, I had to set the target platform flag to x86 in order to get the DLL to register and instantiate correctly on the windows 8 box.
I've been banging my head all day. I've also tried to start the target.exe and use "attach process" to hit the breakpoint, but no dice. I've cleaned the .pdb files, cleaned and rebuilt, etc, to no avail.
Anyone know what I might be doing wrong?
Double-check that your symbols files are being loaded correctly during execution using the dialogue found at:
TOOLS -> options -> debugging(tab) -> Symbols
here you can specify the symbols directories in which visual studio should look for .pdb files.
I finally got it!
Debug->Attach To Process dialog.
Attach to:
Managed (v3.5, v3.0, v2.0) code, Native code. // I changed this from 'Auto'.
My target .NET framework in the DLL's project settings was 3.5. I guess the 'Auto' detect setting didn't work as I thought it would....
A C# desktop application (on the Visual Studio Express edition) worked, but then it didn't work 5 seconds later.
I tried the following:
Ensure debug configuration, debug flag, and full debug information are set on all assemblies.
Delete all bin and obj folders and all DLL files related to the project from my entire machine.
Recreate projects causing the problem from scratch.
Reboot.
I have two Windows Forms projects in the solution. One of them loads the debug information, one doesn't. They both refer to the assembly I'm trying to get debug information on in exactly the same way in the project file. Any ideas?
I want to add here, mostly for myself when I come back to review this question, that symbols are not loaded until the assembly is loaded, and the assembly is not loaded until it is needed. If the breakpoint is in a library that is only used in one function in your main assembly, the symbols will not be loaded (and it will show the breakpoint as not being hit) until that function is called.
Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All, use Debug > Windows > Modules. You'll see a list of all the assemblies that are loaded into the process. Locate the one you want to get debug info for. Right-click it and select Symbol Load Information. You'll get a dialog that lists all the directories where it looked for the .pdb file for the assembly. Verify that list against the actual .pdb location. Make sure it doesn't find an old one.
In normal projects, the assembly and its .pdb file should always have been copied by the IDE into the same folder as your .exe, i.e. the bin\Debug folder of your project. Make sure you remove one from the GAC if you've been playing with it.
Check to make sure that you are not in release but in Debug.
When in debug:
First try rebuilding your project by right mouse click the project > Rebuild
If that doesn't work, try a clean of the project (right mouse click on the project > clean)
If that didn't work check this:
Right mouse click your project
Select [Properties]
Select the [Build] tab
Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Make sure [Optimize Code] is unchecked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)
(step 7 generates the .pdb files, these are the debugging symbols)
Uncheck the "Enable Just My Code" option in the
Tools/Options/Debugging/General
Just something simple to try - you may have tried it already.
Right click the Solution in solution explorer, click "clean solution", this deletes all the compiled and temporary files associated with a solution.
Do a rebuild of the solution and try to debug again.
I've also had troubles with breakpoints multiple projects in a solution - some compiled as x86, some as x64.
The selected answer led me to fix my problem. But I need to do a few things more:
Even with "Debug" selected in the dropdown:
And in the project Properties > Build:
The Visual Studio was not loading symbols to a specific project. So in that dropdown I select "Configuration Manager" and saw that the settings to my web project was incorrect:
Then I set that to "Debug" and it started to generate the .pdb file.
BUT I need to manually copy the PDB and DLL and put in the folder that VS was looking (here is where the selected answer helped me):
Sometimes, even though it gives you this error, the Breakpoint still gets hit, so just ignore the error.
This happens fairly often in the Views of an MVC web app, i.e. .cshtml.
I was able to fix the error by simply setting the option in the 'Attach to Process' to 'Automatically determine the type of code to debug' option as shown in the attached screenshot.
Simply follow the steps below:
Go to Debug from the menu bar
Click on Attach to Process
Near the Attach to option, click on the Select button
The Select Code Type window will appear
Now select the option Automatically determine the type of code to debug and click the OK button.
Debug > Windows > Modules to see what modules were being loaded put me in the right direction.
In my case IIS Express seemed to be loading a different DLL from the temporary ASP.NET files.
The solution?
Browse to C:\Users\<YOUR USER>\AppData\Local\Temp\Temporary ASP.NET Files\vs
Delete everything in this directory!
Check if your .pbd file is missing in your bin/Debug folder. If it is then go to "Properties" of your project, selected "Build" and then "Advanced" at the bottom. Choose "full" under "Debug info" in the new window that appeared. This was my issue and solved it for me.
In my case "Optimize Code" was checked in my project properties. This caused VS to see my assembly as "not my code", and in turn, it did not load symbols for it.
The solution was to uncheck this.
Try running visual studio as an administrator within windows.
You need to enable "Generate debug info" in compiler settings
I tried everything mentioned above, but nothing worked.
[Clean solution, and check for PDB files etc.]
Even publishing the same solution did not resolve the issue.
Then I went to back to what I usually do to resolve (fool this stubborn Visual Studio)
All I did was to make a deliberate change in code and publish the solution.
Then I reverted the change and published again.
Voila [PDB files rid of evil spirits].. Not a smart resolution, but this did work.. :-|
We found the cause of our problem. This code was using the "CodeBehind" attribute in the Page directive of the .aspx file instead of the "CodeFile" attribute (ASP.NET 2.0 and beyond). After days of desperation, a simple search and replace solved the problem.
Option "Start debugging, Debug + Windows + Modules" does not exist in Microsoft Visual Studio Express 2013 edition.
Unchecking "Use Managed Compatibility Mode" in Tools Options Debugging fixes this.
Webapplications (IIS Express) only:
Rightclick IIS Express Tray and close the IIS.
Clean Solution
Clean solution and Rebuild
Check the configuration is set to Debug
Make sure that the PDB file is in the Debug folder it self
From Debug menu click Enable All Break points
Make sure you're in Debug and not is release by choosing debug in the dropdown menu like you can see in the picture below.
Then, try cleaning your project by clicking the right button in your mouse on the solution in the solution explorer window and choosing Clean solution.
Then rebuild your solution by clicking the right button in your mouse on the solution in the solution explorer window and choose Rebuild solution
Check are the following two setting the same in Visual Studio:
Right click test project, go to Properties, Build tab, and look at Platform target
Mine are all set to "Any CPU" so x64
On the Main Menu bar, go to Test, Test Settings, Default Processor Architecture
Mine was set to X86
Changing this to X64 to match above setting made the built in Visual Studio menu “Debug Test(s)” work and hit breakpoints that were previously ignored with the message “The breakpoint will not currently be hit. No symbols have been loaded for this document”.
Update:
For Visual Studio 2019 the menus have been moved around a bit:
I also had the same issue what I rebuild the whole solution (including refereced projects) in x86( or x64)
Even though I set all of my projects to x86 from Configuration Manager (Build->ConfigManager) some of my projects were not set to x86.
So Just to make sure right click on the project and follow
project -> properties -> Debug Tab, verify Configuration and Platform.
The .dll where I want to stop debugger and the associated .pdb files where copied near the .exe file. Those files had an older date so I thought they weren't updated in the runtime. I manually deleted them, Visual Studio create another pair AND put this new pair near the .exe. Now the breakpoint works!
Maybe Visual Studio cannot copy and REPLACE existing files (.dll and .pdb) near the .exe since there are another there. So if I deleted manually then VS could create new one near .exe.
I think that the root cause of the problem is that the Visual Studio use another file in runtime, no the file from the project, with the stop.
Instead of doing all these things just Close and reopen
Project Properties (then select your build config) > Build Tab > Advanced... > Debug Info (dropdown)
Set to 'all' or 'pdb-only' then rebuild
This took me a while tried other options above and for some strange reason debugging stopped working.
Tool -> Options -> Debugging -> General -> (untick) "Require source files to exactly match the original version" option
I was integrating a C# application with a static library using VS10 - which I'm new to. I wrote a managed code dll to interface them. I could set breakpoints everywhere but the static lib. I got the message described above - no symbols have been loaded for this document. I tried many of the suggestions above. I could see that the symbols weren't being loaded. I finally noticed a check box Configuration Debug, Enable unmanaged code debugging. That allowed me to set breakpoints in the static lib functions.
In my case, I was compiling a class library (DLL). No modules seem to be loaded in Debug -> Modules, so I couldn't even load the symbols manually.
My solution was to add this line to my code:
System.Diagnostics.Debugger.Launch();
Once this code is reached, an exception is triggered and .NET Framework shows a dialog box asking which Visual Studio (i.e. new instance of VS 2008, new instance of VS 2013, etc) you want to use to debug the program. You can choose the existing instance of VS with your project loaded. This will attach the process to your VS session and load all symbols, and now you can debug your project.
Of course, the compilation has to be done using the Debug configuration, not Release.
For an ASP.Net application, check the properties of the site, ASP.NET tab. Ensure that the correct ASP.NET version is selected.
I think the source if this error is, the debug symbols have a hard time surfacing to the solution after building for release.
I tried all the other answers -- generally, regenerating .pdb symbols or checking their location, cleaning and rebuilding project, ensuring active configuration is not Release etc.
What eventually worked for me is right-clicking on the project in solution explorer > Debug > Start new instance.
After trying a bunch of these, the thing that ultimately worked for me was this:
In Debug > Options > General, uncheck Enable Edit and Continue.
this happened to me after copy paste another webservice asmx file into an existing webservice, resulting in the same error when trying to debug the recently added service, to be able to debug I had to start without debug, then attach to the process. its weird but its the only way i found to be able to debug.