I've written an event handler for sharepoint 2010 site using visual studio 2010 . I had attached a breakpoint to the code and followed the process which i had done in visual studio 2008.
It is to use the Attach to process option and select the w3wp option.
The event gets attached but the breakpoint is not firing.
I ve checked the site collection and checked the MAnage site settings to see if the event handler is enabled. It is enabled. I tried to disable and enable it again. Even now its not firing.
Also i tried to clean the build solution and re built it . The debugger is not firing.
Do post a reply
Thanks in advance
Baradhwaj.PC
Here are a few things to check:
Are you attached to the correct process?
Using appcmd.exe list wp on the server (IIS7+) can be a useful way to determine which process ID belongs to which App pool. If you attach to the wrong process ID, even if it is the right name, the breakpoint won't fire.
Are your PDB's installed with the .dll's?
When I use GAC-based deployments, I often use a PowerShell script to copy my PDB files into the GAC folder where the assembly lives, usually something like C:\WINDOWS\assembly\GAC_MSIL\MYLibrary\1.0.0.0_publickeytoken.
When using bin-based deployments, it is sufficient to ensure the pdb is also in the bin folder.
While debugging, check the "Modules" debug window.
Find your assembly to determine whether debug symbols were loaded. If they are not, read the reason why. Note that you may need to invoke your code at least once for the assembly to get loaded.
Sometimes, it might mention that the pdb version doesn't match the assembly. This might happen if you built and deployed without pushing out a new pdb, even if you made no changes to the code. If this occurs, just redeploy a freshly-built assembly and pdb.
Are the PDB files in the path in which you are debugging? Without the PDB files, I think Visual Studio will be unable to link your code to the breakpoints.
Related
I have a C++ DLL project in Visual Studio I've downloaded, which is a plugin module for another existing program (a media Player). The DLL created by this project is saved into the addon folder, is loaded by the media player and works great with no issues. However, I would like to be able to step through the code in the library while the player is running to understand how the code works.
The problem is that when I setup the project to launch the media player and step through the DLL project code, it starts fine and I can set breakpoints. But at certain times, the Visual Studio debugger tries to access other loaded DLLs inside the media player, which I don't have source code for, and it crashes the whole thing with an "access violation writing location blah blah blah" error. I have no interest in trying to access any other libraries the program is loading other than the one I have the source code for, so is there any way to prevent the Visual Studio Debugger from trying to hook into these other libraries? I know the error is not due to anything in the DLL project itself because it runs absolutely fine if I just tell it to "Start Without Debugging."
I have the source code for, so is there any way to prevent the Visual
Studio Debugger from trying to hook into these other libraries?
Please try these steps:
Suggestion
1) check Enable Just My Code under Tools-->Options-->Debugging-->General
2) enter Tools-->Options-->Debugging-->Symbols-->choose All modules, unless excluded and then click Specify excluded modules
then input the name of the dlls you want to exclude. Their symbols will not be loaded when you debug your application.
3) do not forget to uncheck option Warn if no user code on launch(managed only) under Tools-->Options-->Debugging-->General
I´m trying to debug a System.Net.Http.Formating.dll, by clicking at the stack trace:
System.Net.Http.Formatting.dll!System.Net.Http.Formatting.JsonMediaTypeFormatter.WriteToStreamAsync.AnonymousMethod__c()
I´ve the "Just my code disabled" and I have the following symbols servers:
https://nuget.smbsrc.net
http://localhost:33417/ (dot peek)
Microsoft Symbol Server
I do have the pdb available, however I get the following error/image.
How to properly overcome it?
Why is it such a hassle to debug third party source code at Visual Studio?
After following the link pointed by #Jack Zhai-MSFT I was finally able to understaand the reasons why the .net framework couldn´t be debugged.
It turned out that the symbols were being downloaded without their respective source, because I was pointing to Microsoft Symbol Server instead of http://referencesource.microsoft.com/symbols
Then, my following attempt was to uncheck the "Microsoft Symbols Server" or to change the order at the Symbols menu. To my surprise, I couldn´t delete it, nor change the order, and, even after it was disabled the symbols were still fetched from there.
Perhaps this is a VS2017 community bug.
What I did next, that actually solved it:
Deleted my symbol cache that had misleading pdbs without source
Enabled just my code flag, disabling “Enable .NET Framework source stepping” and started the app, on debug mode
Paused at a breakpoint in which, at the stack, I had access to the code I wanted to debug
Double clicked such stack, and then hit Load Symbols.
This time around, for some reason, the Microsoft Symbol Server was skipped, and the right pdbs were downloaded
Note that, still, I couldn´t download some "optimized symbols" like system.net.http, but I´ll try to figure that out next
Also, I setup the symbols servers using that as a reference, which helped me to promptly get any third party symbols (Except .net)
https://www.symbolsource.org/Public/Wiki/Using
EDIT:
With the help of dotPeeker I was able to get all the missing pdb files by:
Loading these dlls into dotpeeker (ex: System.Net.Http)
Load one of the source files from that DLL
Hit Generate PDB and store it into the same cache folder as VS2017 uses
PHEW!! What a hassle for something that should have been trivial!
To debug third party source code, you could use the .NET Reflector or dotPeek with VS.
Reference:
Is it possible to actually debug 3rd party code using the source decompiled with dotPeek?
Update:
If you just want to debug the .NET source code, see: How do I debug .NET 4.6 framework source code in Visual Studio 2017?
I'm trying to get remote debugging working to an AOS. But my breakpoints never get hit due to symbols not being loaded.
'Ax32Serv.exe' (CLR v4.0.30319: X++ IL App Domain): Loaded 'D:\Program
Files\Microsoft Dynamics
AX\60\Server\MyAOS\Bin\XppIL\Dynamics.Ax.Application.dll423.netmodule'.
Cannot find or open the PDB file.
I have my debugging symbols setup to:
\server\d$\Program Files\Microsoft Dynamics
AX\60\Server\MyAOS\bin\XppIL
But visual studio never loads the symbols into the cache.
I'm running Visual studio as Administrator
My client configuration settings are linked to the correct AOS
I'm connecting to the AOS with the AOS-account
I'm local administrator on the AOS server
Debugging options are checked on the server configuration
Any idea what I'm missing or not doing correctly?
Procmon is telling me that the devenv.exe process can't access below path (PATH_NOT_FOUND). But I'm clueless on why it's trying to access this path.
\server\d$\Program Files\Microsoft Dynamics
AX\60\Server\MyAOS\bin\XppIL\Dynamics.Ax.Application.dll33.pdb\63A38861AB9B4E6EA55578A367A991AD1\Dynamics.Ax.Application.dll33.pdb
According to my experience deployment of assemblies hinders a proper use of Remote Debugger at AOS side.
The following steps didn't help in my circumstances:
VS symbol cache set to a local path with PDB files (VS at a remote box caches a project from AOT).
VS symbol cache set to a shared folder (AOS PDB files are exposed to a network).
Attempts to find proper order of AOS restart / clean debug information in order to sync versions of loaded DLL and loaded PDB.
AOS option "Assembly hot-swap" didn't help either. It works, however PDB and DLL are not in sync.
Tinkering with DL3 / VSAssemblies AOS folders didn't reveal any workarounds.
Eventually it was found a possible way to overcome "Missing symbol information" message which is a root cause here in my opinion. There were a couple VS projects residing at AOT which were subject for remote debugging. Every attempt showed no luck due to the same "Missing symbol information" error.
I hope the following scenario could help OP to find a solution for AIF web service:
Append CSPROJ manifest with the following lines:
<VSProjectOutputFiles Include="$(OutputPath)$(AssemblyName).pdb">
<Visible>true</Visible>
</VSProjectOutputFiles>
This helps to save PDB artifacts into AOT tree.
Compile VS project at MorphX IDE. Compilation of project at AOT is essential here, as it deploys matching PDB alongside DLL.
Restart AOS. Hot-swap didn't worked for PDB, so restart is mandatory here. As a result you can see proper PDB within "Modules" window at VS and breakpoints are reachable now thanks to that fact.
Although using Remote debugger looks truly appropriate for AOS (not to bloat server with dev tools), it seems there are still some kinks in relation to AOS code deployment.
Breakpoints don't hit and Cannot find or open the PDB
My breakpoints aren't hitting in a known good class. I know the class is working becuase the data is flowing through. They worked yesterday. I also tried a class that I haven't touched in weeks (another known good) and the breakpoints wouldn't work there either.
I have:
- Verified I am building in debug mode
- In my solution > Properties Configuration Properties > Configuration I verified each project is set to Debug and Build
- Went to Tools > Options > Debugging and disabled "Enable Just My Code"
- Cleaned and rebuilt the solution
- Restarted Visual Studio
- Rebooted my computer
I have the Modules window open in Debug. Many of my modules show "Cannot find or open the PDB file." Many show "Symbols loaded" (that is good.)
For the files that do not have matching PDBs I right-click and go to Load Symbols From > Symbol Path. Of course there is no PDB in the symbol path. When I right-click and go to Load Symbols From > Microsoft Symbol Servers I get nothing. I have searched the root of my drive looking for these specific PDBs.
Here is an example of the affected DLLs:
Microsoft.CSharp.dll
System.EnterpriseServices.dll
System.Runtime.Serialization.dll
System.Web.WebPages.Deployment.dll
System.Web.ApplicationServices.dll
Based on what I found online the PDB issue is realated, but if I can hit my breakpoints withouth PDBs then I'm happy.
I checked out: Visual Studio 2010 "Cannot find or open the PDB file" with no joy.
I would really like to hit my breakpoints.
Thanks!
PDB files should be in the bin directory along with your other files. They are created when you compile your project. If they are not there, you may have turned them off even while in debug mode. For Vb, look under MyProject->Compile->Advanced Compiler Options and make sure Generate debug info is set to Full. Not sure what the analog in C# is though.
Also for a web project, I had this problem when I had a release version running in the same app-pool as my debug version. Try using a dedicated app pool for your debugging if that's the case.
OK, this is totally embarrassing... I wanted to step through my web services, but to do so I needed to send information from my client application. I had my client app pointing at the wrong server. Bummer.
.Net Reflector can generate the PDB files for most assemblies referenced in your project. I have found it to be extremely helpful.
http://www.red-gate.com/products/dotnet-development/reflector/
Once installed, in Visual Studio: View > .NET Reflector Object Browser > Right click assembly and 'Enable Debugging'
I am using VS 2010 professional [64bit - Windows 7] and in my solutions, i have 3 class library project and 1 wcf service projects are there. All these dll's are refereneced in my WPF applications. For the last 1 year, it was working fine and i was able to debug the all the referenced projects. But from yesterday itself, debug is not working all of a sudden.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
When I checked in the Debug --> Windows ---> Modules window, all those projects dlls are not seen there and says no pdb files are available ???
But in the WPF bin\Debug folder, i have all the referenced dlls and their pdb are ther.
What could be the problem ?
Even I am not able to debugg the wpf project as well. For getting break point or debug, each time i have to clean the solution or project then rebuild it again. Then i will be able to debug the WPF project.
In the case of referenced dlls, I removed the dlls and added the new compiled dll again and copied that pdb files to the wpf project exe folder. Still no use !!!!
I have changed the options in the Debug and Options [disabling and enabling the Just my code options etc]. But still it is not working.
This is not only my problem. One of my colleague also have this problem we took the whole latest solution code from TFS. SO I changed the Local code path to a new folder and took the latest code from TFS again. Still the problem exists !!
I am able to run the application. But debug is not working. In the WPF project, all those dlls are referenced properly.
Can anyone help us ???
I guess I don't have enough points to comment to ask specifics, so this may or may not solve your problem but I'll take a crack at it. Also, there appear to be other questions about this. So I would check those out first to see if they will help.
This question was solved by adding configuration to tell the program which version of the framework to use during debugging.
Why doesn't VS2010 debugger stop at my breakpoints?
Why does Visual Studio 2008 skip over my break points?
If those don't help, I'll give it a go.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
This sounds like it could be one of the following issues:
Remote debugging and Visual Studio does not know where to load the symbols from or they are out-of-date
Need to clean and rebuild (which you seem to be doing)
The server you are running your WCF service on is not getting the updated DLLs and PDB files. If it's IIS Express, try killing the process between builds.
Also, make sure you are building in Debug mode and not Release mode. While building Release mode will generate the PDB files if it's set to do so which will allow you to debug an application, the code may be optimized as well which can cause breakpoints to be missed.