Setting up remote debugging is always a precarious thing, no matter what kind of development platform: the online documentation tells you the standard steps, but usually they don’t suffice.
This case is Visual Studio 2010 remote debugging, where the development environment is on a workstation running Windows 7, and the debug target is on Windows Server 2008 R2.
Both are x64 versions.
There is a remote desktop connection to the server, and the server can see the workstation files on the \\TSCLIENT\C share.
This is the error when running msvsmon.exe from \\tsclient\C\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64:
[Visual Studio Remote Debugging Monitor] The following error occurred: Not enough storage is available to complete this operation. View Msvsmon's help for more information. [OK]
(Funny BTW that the x64 Remote Debugging Monitor is in fact in an x86 path).
The solution is simple: copy the x64 directory local, then start it from there.
The reason in that the user credentials on the server don’t have enough rights on the \\TSCLIENT\C directory tree, so Windows barfs on it.
This pointed me into the right direction when I started Process Monitor from the same \\TSCLIENT\C share:
[procmon.exe - Application Error] The application was unable to start correctly (0xc000000f). Click OK to close the application. [OK]
Since 0xC000000F means STATUS_NO_SUCH_FILE (File not Found), I copied Process Monitor locally to find out what happened while starting the Visual Studio Remote Debugging Monitor.
There I could see that msvsmon.exe exited with code -2147024882 (which translates to 0x8007000E – E_OUTOFMEMORY):
Date & Time: 20-3-2011 10:07:28 Event Class: Process Operation: Process Exit Result: SUCCESS Path: TID: 7324 Duration: 0.0000000 Exit Status: -2147024882 User Time: 0.0156250 seconds Kernel Time: 0.0312500 seconds Private Bytes: 2.240.512 Peak Private Bytes: 2.326.528 Working Set: 5.910.528 Peak Working Set: 6.127.616
I think the major differences are caused by these two entries; first the \\TSCLIENT\C one (returning “NO SUCH FILE”), then the local one (returning “NAME NOT FOUND”):
Date & Time: 20-3-2011 10:07:23 Event Class: File System Operation: CreateFile Result: NO SUCH FILE Path: \\tsclient\C\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe.Local TID: 8480 Duration: 0.0055796 Desired Access: Read Attributes Disposition: Open Options: Open Reparse Point Attributes: n/a ShareMode: Read, Write, Delete AllocationSize: n/a
Date & Time: 20-3-2011 10:16:02 Event Class: File System Operation: CreateFile Result: NAME NOT FOUND Path: C:\Users\Administrator\AppData\Local\Temp\2\RemoteDebugger\x64\msvsmon.exe.Local TID: 7380 Duration: 0.0000116 Desired Access: Read Attributes Disposition: Open Options: Open Reparse Point Attributes: n/a ShareMode: Read, Write, Delete AllocationSize: n/a
After this difference, the local copy gets a whole bunch of ReadFile operations, whereas the \\TSCLIENT\C version just exists.
Lesson learned: don’t share stuff over \\TSCLIENT\C, just copy it to the remote machine, then use it.
Now I can start remote debugging.
–jeroen
Filed under: .NET, Debugging, Development, Remote Debugging, Software Development, Visual Studio 2010, Visual Studio and tools
