I have sit up remote debugging on a Window 2003 server accessed through the Internet. I have VS 2008 SP1 installed on my XP dev box.
I launched the site on the remote server and attached to all the w3wp.exe processes on the remote server. I noticed that the .dll did not load the symbols file. When I try to load the corresponding .pdb file from my local machine, it says file does not match. I have "Require source files to exactly match the original version" unchecked. The assembly on the remote server is the same as the one on my dev box. The site and .dll was copied from dev boc to remote server and code hasn't changed since. So I know .dll and .pdb files should match or at least I need to force the matching.
Questions:
How do I get the .pdb file to load? I know breakpoints won't trigger unless symbols file is loaded. I noticed that the .pdb file does not exist in the "Temporary ASP.NET Files" folder on the remote server. The .dll does.
What's the proper sequence to start debugging remotely inside VS? (Remote set up is done and I can see remote processes).
In VS, I have start page as the url of the remote site. I start without debugging and then attach to w3wp.exe(s) on the remote. Is this all?
Are you running a Web Site or a Web Application (is it a compiled project, that you deploy the DLL for, or a collection of aspx and aspx.cs files that you deploy)?
If it's a Web Application, did you deploy a release build, or a debug build? You won't be able to hit breakpoints when "debugging" a release build, as the code is fairly heavily optimised.
Have you got "debug=true" set in the web.config compilation section? If not, again, debugging is going to be difficult.
Finally, the steps I use when remote debugging are:
Deploy latest debug build of files
Request page on remote server to start/restart application
Ensure that the VS Remote Debugging Monitor is up and running on the remote server
In VS, go to Tools (or Debug) | Attach to Process..., ensure that the remote server is selected in the Qualifier, and select w3wp.exe for the correct app-pool, etc.
Request page that will fire break point.
Debug!
If the breakpoints are hollow (thin red circles rather than filled disks), I'll often check the Stack window in VS to see what has and hasn't been loaded.
Related
I'm using VS2012 to try to remote debug a service running on a remote server on our network.
I have created a shared folder on the remote server that points back at my development machine and allows me to start the msvsmon.exe 64 bit
I have copied the dll and pdb files from my dev machine to the server for the service i wish to debug. These files are identical.
I can attach to the remote process.
At which point my breakpoints state "No symbols have been loaded for this Document".
"Enable just my code" is NOT ticked.
Service web.config has Debug="true"
I've restarted the appPools since loading my assemblies.
When i debug locally the loaded modules window shows the assemblies i want to debut as "Symbols loaded" If i attach remotely the none of the assemblies even appear in the list.
I'm not sure if this is important for remote debugging or not. If it is I don't know how i can fix this.
Assemblies and pdb files are together in the same folder on the remote server.
However, i read that the dll and pdb files must be the same file structure as on the DEV machine.
I don't know if this is right, but i don't see how this would be possible. VS structure are individual project and solution. Once deployed the assemblies all sit in the same bin folder.
Can any one provide any additional possible causes for this issue ? Can the loaded modules issue be fixed if indeed it is an issue?
Thanks
I have an ASP.Net application who's code is sitting in an Azure Repo. The project has a build pipeline that builds on master branch merges. I then have a Deployment pipeline that takes the latest build and deploys local on my web server through a deployment pool I have running on my server. The web application builds with the VS Build task and deploys with the IIS Web App Deploy task. Both work fine.
I have one VM in with Visual Studio that I am trying to use to remote debug the web server. I have VS Remote Tools on the web server and it successfully runs. On my VM, I am able to open VS, attach debugger to a remote process on the web server successfully. The problem is that the symbols are not loading and I'm not sure what the correct sequence of items is here.
First, it doesn't appear that there are any .pdb files in the build produced by the Azure Pipeline. Second, I'm not sure what is the proper way to get the code onto the VM for debugging (Clone repo, vs download zip, etc). Third, I attempted to add a Publish Smybols task to my deploy pipeline, however its generating .pdb folders not files, and I'm not sure where to place these either on the web server, or on the vm.
My background is in classic local TFS setups, so working, building and deploying from Azure DevOps has me confused on how to get remote debugging to work.
OK this is not for the faint-hearted. It has taken me 3hrs to slowly work through this - but it's worth it. Many times has something worked locally, but then when you trigger an Build Agent with CI on a remote server you can't Step through the code with breakpoints.
So this info is if you are using the above situation - Azure build agent and Continuous Integration. If you are using a Publish Profile this doesn't apply.
First things first... The most important parts of this answer can be found in this blog:
https://willys-cave.ghost.io/i-have-a-dream-of-a-single-build-consistent-x-and-simple/
I've added that Url to the wayback machine at archive.org in case it disappears.
So yes the problem is the .PDB files - they need to be included by adding Publish symbols task. in your VSO pipeline.
Note: I had to change the BuildConfiguration parameter to debug (different from Willy's instructions). Otherwise when you eventually start to hit breakpoints the code is optimized and you won't see variable values in the hover-over etc.
In VS 2019 Willy's instruction for Link to the symbols during remote debugging sessions needs reading carefully. I didn't. There is a better image on:
https://devblogs.microsoft.com/devops/vsts-is-now-a-symbol-server/
I include the screen capture here:
Importantly you need to add your VSTS hostname into the list of Symbol Servers
Now mine still wasn't hitting the breakpoints and I found this page (which is generally about using the slightly different method of Publish Profiles), but I noticed some more components were loaded into IIS... Yes! You may need these too.
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-azure?view=vs-2019
So the most important image I will paste here:
You need to add IIS Management Scripts and Tools to your IIS installation.
That should do it. Also I run my remote debugger as Administrator, attach it to the w3wp.exe (show All Users Processes) and if it doesn't appear - reload the remote page and Refresh as if the pool goes to sleep you won't see it in the list
Good luck!
This is more a 'why does this work this way' than a 'how do I make this work' sort of question.
I have a WCF web service I am debugging remotely. It is deployed to a staging server where the VS 2010 remote debugger is installed and running as a Windows service. The permissions are correct, I can attach to processes without any problem. The issue I ran into is I couldn't consistently get the symbols to load.
I have the WCF service deployed to C:\Webs\MyService, with assorted DLLs in C:\Webs\MyService\bin. It is set up as a separate site with its own app pool. What I found is even if I had the necessary .pdb file in the bin folder, Visual Studio wouldn't load any symbols when I attached to the w3wp.exe process from my local machine. What was happening is when IIS started and the worker process was spawned, my service DLL would get copied deep under the temp ASP.NET files directory, into something like C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\19f82539\e55fff8f\assembly\dl3\2926a261\f625d158_f62ecd01. I found that if I manually copied the .pdb file to this folder, then symbols would be loaded and I could do the debugging.
I'm wondering why the heck it works that way, and how I can avoid having to manually copy the symbol file to this other directory. What's worse is if I had to make changes and redeploy, the worker process wouldn't recognize them. I had to restart IIS which caused a different temp directory to be created, requiring me to copy the .pdb again.
I have a similar problem, with web applications. Apparently Microsoft are aware of this: http://go4answers.webhost4life.com/Example/remote-debugging-symbols-not-loaded-207525.aspx
Hopefully, they will release a fix soon.
There is also a suggestion by BrianR on a related question, Why are no Symbols loaded when remote debugging?, saying to create a folder with the debug files and on the remote server to point the environment variable _NT_SYMBOL_PATH to it.
I did this several time before, without any problem.
But somehow, this time it simply doesn't work.
Systems:
Remote PC: VPS, Guest Win2008R2 x64 dual core (hosted on VMWare Server), VS 2008 remote debug x64 Sp1, application ASP.NET 2.0, isolated in own classic app pool. All updates applied. Host (if matters): AMD Phenom quad core
Develop PC - Win7 x64, VS 2008, all updates applied
I can connect to remote PC with Attach to Process. If I stop and start the app pool while "Attach to process" is open in VS, I can see the process and (apparently) I can attach to it.
However, the breakpoint briefly get activated (red, filled) then immediately gets deactivated (red empty circle) and of course it doesn't stop the application.
I searched on google and found very few references. One suggested to copy the *.PDB in asp.net temporary files, and even if there there are lot of dirs with subdirs (one for each dll) I copied all PDB in temp folder with the dll. No success.
I'm running out of ideas. Does anyone feced similar issue? Any thoughts?
Thanks
You need pdb files for the same. Copy the actual pdb files of the dll from the development project. It will be inside the bin/debug/ directory of your original project (source code one not the deployed). Then copy the pdb file to remote directory where the dlls resides and then attach the debugger. Also for that , you need Remote Debugger.
I have an ASP.net that I built in VS2010 running in iis7 however when I go back into VS and make updates to the code behind file and re-publish the application still acts as it has before I made the changes. I have tried deleting and republishing all the files and restarting the app pool but it still doesn't affect how the application behaves.
project-->Property's--> Package / product web--> Items to deploy --> All files in this project folders
now publish your project.
your new files also added in publish folder. . .
DO NOT publish your vb and cs file on there server unless you feel like having your source code potentially exposed. There have been multiple vulnerabilities that have allowed code download.
Publish the application to a folder via the visual studio publish menu.
On the server, go into your temporary aspnet folder for example:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
and find your app and delete it. If you cannot delete the files stop the worker process (w3wp.exe) or restart iis.
Republish and all should be good. If you are in doubt if that version is getting executed then add some logging in the new version or trace information.
There are two options for publishing an ASP.NET site to a server:
Copy the .aspx AND aspx.vb (or .aspx.cs) files to the server. The first user to hit the server causes compilation so it takes a little bit of extra time for them. Once that's done, subsequent hits should not be impacted.
Copy just the .aspx files - and a compiled DLL to the server. The DLL contains the compiled code so it doesn't exist on the webserver. The first user does not have to wait for compilation and the VB or C# source code is not on the server, potentially accessible to hackers.
It sounds like you've compiled the site to a DLL but that DLL isn't getting published to the server when you re-publish. Have you recompiled the site before publishing?
I faced similar issue with WPF single file exe publish.
while debugging from VS my changes were visible.
But when I pasted the exe to deployment folder, the changes weren't there.
I had to change the version number to see my changes when I run the exe from the deployment folder.
I may have to do with how single file exes are handled. The extracted cache may not be getting updated.