Is it possible to attach once in native, then open second VStudio window and attach in managed mode?
You can attach WinDbg as non-invasive, which allows you to attach even if another debugger such as VS is already attached. There's a check-box in the popup for Attach to process.
However, doing so will not allow you to control the application from WinDbg as only one debugger may control the debuggee. You can still view memory, threads, etc. (and you can load SOS/PSSCOR2 to inspect managed data).
You can only do this in .NET 4.0
Related
I have several apps hosted in IIS that are running at the same time. When I attach to a process in the Visual Studio debugger, I see several w3p processes. The only way I can tell which one to attach to is by trial and error (if I attach to the wrong one, the breakpoints say they will not be hit). How can I know right away which process to attach to?
Using the taskmanager, view processes, add column process id.
Trigger a page to see some CPU usage. Now you know the process to attach to.
Unless you've changed app pool settings, the name of the application pool will appear as part of the "User Name" in the attach window:
What would be really nice would be if this user name could also appear in the Processes window, so when attached to multiple processes you could figure out which was which. But that doesn't seem possible.
Is there a facility in Visual Studio, when debugging a desktop app, to remember where the mouse was when I hit a break point so that i may use it in Visual Studio while stepping through code, and then snap it back to that spot when I resume execution? This would help in mouseover events and other position-sensitive workflows.
If there's not something built in, would it be possible to do this with a Visual Studio plugin? Or is there a way to install a hook such that the debugger sends my application an event or interrupt that it could use to save that state on break and restore it on resume?
Thank you.
There's nothing built in to the VS debugger to do this. It's more than mouse position, there are likely subtle state changes (like focus and activation) that would be difficult to save and restore reliably.
A quick and dirty thing to do is to add some OutputDebugString messages to the code in question to give you clues as to what's going on internally without actually breaking the execution. VS will show the messages in the Output window.
The only way to come anywhere close to what you're after is to use remote debugging. You can remote debug your code running inside a virtual machine so that you don't actually need a separate physical machine.
When my program is paused in Visual Studios 2010 during debugging, like from reaching a break point and me doing a manual step through, the program window becomes impossible to view.
It is a GUI window not a console window, which I run simultaneously with my program and am still able to view. The window seems to be open it's just that when I click its icon on the taskbar it doesn't come to the front of all the other windows. When I minimize all the windows in front of it, I see the outline of the window but it is either blacked out or showing the remnants of previously expanded windows.
I've noticed this with using Visual Studio's before (various versions of it), and after trying other IDE's that didn't have this behavior I notice it more. It would be really helpful to view the program's change's as I step through the program. Anyone know how I can do this?
I searched a long while and couldn't find a single reference to this matter.
The reason the window doesn't display is that the window paint message won't be processed if the main thread has been paused. Which other IDEs let you do this? I haven't come across any native code debuggers that do this on Windows.
If you are stepping through code that is run by the main thread, then the main thread can't simultaniously poll the message pump, which is needed for the GUI to work.
If you debug a different thread, the GUI will work while you are debugging.
Is there any way that I can understand that my code is running with Ctrl+F5 or F5?
I wrote a GUI for an application for some students but it doesn't work some time when run it with F5...I want too detect F5 and Ctrl+F5 mode to disable GUI when user run it with F5.
CTRL-F5 runs the application without the debugger attached. You can tell if it was started with plain F5 by checking the System.Diagnostics.Debugger.IsAttached.
If the GUI sometimes breaks when run with a debugger attached, it is likely because you use multithreading incorrectly to access UI properties in a thread other than the main UI thread.
You can use the System.Diagnostics.Debugger.IsAttached Property to tell if a debugger is attached or not, i assume that's what you mean.
Hope that helps
Paul
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.