I spoke with Microsoft recently regarding a setup problem that I have been having with Visual Studio, and we seem to have resolved the problem. Specifically, I had been having a problem starting the debugger from InterDev. Even the simple ("hello world") project that is used to test the installation of the tool failed in the same manner. The messages returned indicated:
"Unable to set server into correct debugging state automatically. You may not be able to debug ASP pages. Do you want to continue?"
I answered <yes> and got the following:
"Application 'C:\Program Files\Internet Explorer\iexplore.exe' failed to launch. "
The problem seems to be caused by Dell shipping their PCs with the .NET framework installed. The specific culprit files are
pdm.dll
mdm.exe
which are found, for v6, in the "system32" directory, but were also on my laptop in "Program Files\Common Files\Microsoft Shared\VS7Debug". Further, the service "Machine Debug Manager" was running, executing the "VS7Debug\mdm.exe" file -- consistent with the .NET debug framework running on the machine.
To solve my problem, we stopped and disabled the "Machine Debug Manager" service, unregistered (regsvr32 -u) the "VS7Debug\pdm.dll" and renamed pdm.dll and mdm.exe in the VS7Debug directory to "_OLD". We then registered (regsvr32) system32\pdm.dll, ran the debug installation from the Visual Studio disk (disk2 SCRPT_SS\Setup.exe), and rebooted. I still get the "Unable to set server into..." message, but both the debugger and Internet Explorer start correctly and can be used. It seems that the problem has been resolved.
It is interesting to note that some of my colleagues have the "Machine Debug Manager" service running but can use the Studio v6.0 debugger correctly. Perhaps it depends only on which DLL is registered; this is unclear for now. Also, it is probably true that explicitly registering the v6 pdm.dll AND running the debugger install were redundant since both are intended to enable the v6 debugger, but better safe than sorry.
Microsoft indicated that a KB article will not be posted unless at least three calls are received with this problem. My Visual Studio environment has been functioning correctly since this modification.
"Unable to set server into correct debugging state automatically. You may not be able to debug ASP pages. Do you want to continue?"
I answered <yes> and got the following:
"Application 'C:\Program Files\Internet Explorer\iexplore.exe' failed to launch. "
The problem seems to be caused by Dell shipping their PCs with the .NET framework installed. The specific culprit files are
pdm.dll
mdm.exe
which are found, for v6, in the "system32" directory, but were also on my laptop in "Program Files\Common Files\Microsoft Shared\VS7Debug". Further, the service "Machine Debug Manager" was running, executing the "VS7Debug\mdm.exe" file -- consistent with the .NET debug framework running on the machine.
To solve my problem, we stopped and disabled the "Machine Debug Manager" service, unregistered (regsvr32 -u) the "VS7Debug\pdm.dll" and renamed pdm.dll and mdm.exe in the VS7Debug directory to "_OLD". We then registered (regsvr32) system32\pdm.dll, ran the debug installation from the Visual Studio disk (disk2 SCRPT_SS\Setup.exe), and rebooted. I still get the "Unable to set server into..." message, but both the debugger and Internet Explorer start correctly and can be used. It seems that the problem has been resolved.
It is interesting to note that some of my colleagues have the "Machine Debug Manager" service running but can use the Studio v6.0 debugger correctly. Perhaps it depends only on which DLL is registered; this is unclear for now. Also, it is probably true that explicitly registering the v6 pdm.dll AND running the debugger install were redundant since both are intended to enable the v6 debugger, but better safe than sorry.
Microsoft indicated that a KB article will not be posted unless at least three calls are received with this problem. My Visual Studio environment has been functioning correctly since this modification.