When I 'm remotely debugging an executable, I have it available in the remote machine along with its (500 MB) PDB.
When I start the remote executable, the local Visual Studio takes a LOT of time to finally run it - the messages about DLL's attaching are going super slow in the output window. Debugging is also slow when the app is finally responsive after attaching.
It's like as if it's trying to exchange some debugging information back and forth with my PC, although the EXE and PDB are there.
Is there anything I can do to speed up this? I 've even placed the remote folder for msvsmon to find in tools -> options -> debugging -> symbols.
Related
I have recently bought new laptop:Hp specter x360 i7-6500 with 8gb RAM.
I have installed Visual Studios 2015 Community in an offline mode, later I updated it.I am currently working in c# window forms.
The point is when I press the button 'Start Debugging', VS build the program in normal speed, but it takes like 10-15 sec to show the output, even for the small programs. This whole thing is for first time debugging after code editing, if I close it and run it again without changing the code, it shows the output on the spot.
And if I run the same program in my old laptop, which has lower specs and same VS, that laptop show the result much quicker.
Based on your screenshot, I see that VS tries to download PDB symbols for system assemblies, which are used by your application. Loading the debug symbols provides simplify debugging of an application but it also slows down the application loading.
You can change symbols loading settings, in the Tools-Options-Debugging-Symbols menu of Visual Studio. Here you can disable symbol loading (if you would use this option you need to load symbols manually using the Debugging-Windows-Modules interface). Or exclude system modules which usually are not necessary to debug a common application.
Check this blog post which provides a great description about how VS uses debug symbols.
I'm looking for tips for those who to develop for Windows XP embedded in Visual Studio2013, then debug in Visual Studio 2010.
The reasons for this are discussed in this Stack Overflow Link on the topic.
Essentially the remote debug protocol changed after VS2010, and the new msvsmon.exe which uses the new VS2013 protocol doesn't support XP embedded debugging. So we are forced into a TWO IDE solution, one for builds, another for debug. VS2013 is used for builds, and VS2010 is used to launch remote debug sessions.
There is some misinformation about the requirement to purchase both VS2013 and VS2010. It appears from the previously mentioned link, that it's possible to obtain the VS2010 debug environment for free. I was able to verify the free download of the components, but haven't had time to validate that the debug environment works. The environment I use consists of a licensed copy of VS2013 and a licensed copy of VS2010.
Here are two initial problems which I haven't seen doing remote debug in the former VS6 msvsmon.exe environment:
1) With VS2013 build projects, VS2010 does not want to open the *.sln file. If I open the VS6 .dsp/.dsw we ported from VS2010 does a "ONE TIME CONVERSION" which destroys my painstakenly built VS2013 build project.
It seems I will have to build TWO different solution spaces, one named SOLUTION_NAME_VS2013 and another SOLUTION_NAME_VS2010. I'm interested to know if there is a more elegant solution to manage 1 set of BUILD files with two different "Highlander" (there can be only one) IDE's.
2) When starting up the project remotely, if it crashes I get one of those annoying "Your program has crashed" dialogs on the Win2012 debug host (running VS2010), which is trapping the crash signal from the debugger. About 30% of the time, it detects the running instance of VS2010, 70% of the time it doesn't.
3) msvmon times out (needs restarting) and requires extra time/mouse clicks to setup over the old vs6 msvcmon.exe
I'm wondering if other Windows Embedded developers have discovered elegant solutions for these issues. I'll post what I find here if I find any more tips moving forward.
For Issue #1: Unable to read VS2013 *.sln file in VS2010.
The problem was that the VERSION of Visual Studio 2010 must be at least SERVICE PACK1. Earlier versions of Visual Studio 2010 cannot read the VS2012/VS2013/VS2015 solution files.
For Issue #2: Your program has crashed dialog preventing signals from reaching debugger.
This Stack Overflow link was helpful. There are multiple ways to suppress the "Your program has crashed" dialog. In my case, users may need to debug new applications on a production system, so changing the setting globally is not ideal.
I choose the solution from this Raymond Chen link it allows me to disable the dialog box on an application by application basis. Since I typically have access to source code I'm debugging this was the best solution for me.
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I still see an issue occasionally with the Windows runtime not seeing the running debugger instance on a crash and wanting to initiate a new one. This seems to happen ~30% of the time. When I figure out what is causing that I will update it here.
Finally, the new remote debug client changed to msvmon.exe which has improved security. To save the extra mouse clicks, the following command is usefull to run on the remote Windows Embedded XP client:
"Path\to\msvsmon.exe" /anyuser /noauth /nosecuritywarn /timeout:2147483646
The /noauth and /anyuser require /nosecuritywarn. /timeout max value keeps the debugger client from terminating after ~ hour of idle time. If your workday is to be spent debugging you don't want it timing out after a coffee/rebuild all break.
I have read this question and this page linked to in the question, as well as dozens of other articles about debugging asp classic with VS but it's still not clicking for me.
I am using VS 2010. The files I want to debug live on a remote server. I have installed the Remote Debugger on the server. I opened the website and attached to the w3wp.exe process on the remote machine. I created some breakpoints but I am still getting "The breakpoint will not currently be hit. No symbols have been loaded for this document" on those breakpoints. Is that the problem or is that a symptom of a larger problem with what I am doing?
First, by default, when you open a web site in Visual Studio, you're opening it via the file system, not via IIS. If this is the case, then Visual Studio uses the internal Cassini web server, rather than IIS.
The Cassini web server does NOT run classic ASP. IIS does. So the first thing you need to do is figure out how to debug in IIS.
It should go without saying, you need to have IIS installed on the machine you're working with, and have the web site you're debugging set up the same as it would be on the server. (so you should be able to run http://localhost/somepath and be able to see your site)
You also need to attach to the running process of Internet Explorer. There's a link to that as well.
Next, you need to get Visual Studio to attach to IIS and execute the web site rather than use the built-in web server and enable debugging.
That's covered here: This topic is no longer available (which is the first child link of the page you liked to in your question here.
From there, you should be able to follow the remaining links and get up and running.
Edit - added
This article takes you through it step-by-step.
Debugging Classic ASP ( VBScript ) in Visual Studio 2008
I've just had this problem when trying to debug a classic ASP application in VS2012.
There's no need to copy PDB files, because there aren't in this kind of projects, so follow this steps:
Be sure that ASP compatibility is turned ON in your IIS installation (Control Panel -> Enable/Disable Windows features -> Internet Information Server). You can install all features if you want to be sure.
Access to the IIS administration.
Locate your WebSite, then access the ASP configuration.
Find "Debugging properties" and then enable client and server debugging. You can also enable error sending to the browser.
After that, just attach the VS2012 debugger to the "w3wp.exe" process. DEBUG -> Attach to process....
This will work for local debugging. If you want to do remote debugging, you must prepare the remote server to allow remote debugging (TIP: Use the same user in both, server and your machine, and be sure it has enough privileges). For more information take a look at:
Installing the Remote Tools
Debugging Classic ASP ( VBScript ) in Visual Studio 2008
I have installed the VS 2008 SP1 Remote debugger on the machine running the program I want to debug. I am running the Remote Debugger with no auth / allow anyone to connect on said machine. I am running VS 2008 on my development machine with the project for that application open. I have copied a .dll that i have made changed to the source and rebuilt, locally, to the executing directory of the target program, remotely, including it's .pdb file. I have attached to the process of the remote application though VS and the Remote Debugger.
The break point I put in my project says that it will never be reached because the module is not loaded.
An exception on the remote machine, even when i select retry, dose not cause any effect on my local VS instance.
I want to hit a break point i place locally when the remote application reaches it. How do I do this?
Am i miss understanding how Visual Studio Remote Debugging works?
Is the breakpoint the normal red circle or does it have a caution side in it?
If it's a red circle then the likely problem is "Just my Code" is enabled and VS thinks it's not your code. Go to debugger -> Tools -> Options and disable "Just My code". That should clear up the issue.
If it has the caution sign then hover over the break point and see what the error message says and please post it back as a comment / edit to your answer.
EDIT OP said hollow circle with the "No symbols" tooltip
Open up the modules window (debugger -> windows -> Modules). Then scroll down to the DLL that contains your code. Right click on the window and select Load Symbols. This will likely open the open file dialog. Navigate to your symbols and hit OK.
Have you installed Service Pack 1?
http://support.microsoft.com/kb/957912
Visual studio debugger hangs while loading symbols for my application(native IA64), SP1 is installed. This started to occur, after i install debugging tools for windows(64 bit version), and reboot my computer. This issue is not depend on my project, even with new project debugger hangs.
UPDATE:
When i try to attach to the running process, the same situation repeats. Visual studio hangs while loading symbols(for kernell32.dll)
symsrv.dll is responsible for loading symbols from a symbol server - you might try renaming the one installed by Debugging Tools for Windows and see if the VS debugger starts working again.
Is it completely hanging, or just taking a long time to load the symbols?
If you using a symbol server to access debug symbols for the Windows DLLs, VS2005 can try to access the symbol server every time you debug.
The way around this is to load the symbols once, and then uncheck the symbol server URL under Tools->Options->Debugging->Symbols. As long as the OS libraries haven't changed since you last downloaded the symbols, there's no reason to access the remote server every time.
Also see this answer.