Has anyone gotten a debugger attached to mshta.exe after installing IE9? (64bit or WOW64)
If you have Visual Studio, go to Tools -> Attach to Process and attach to the MSHTA.EXE process. Then pick Script as the target to debug.
I'm on a Vista x64, so I have to contend with the 32bit/64bit barrier.
HTA
c:\windows\system32\mshta.exe
(mshta32)
c:\windows\syswow64\mshta.exe
(mshta64)
Launching
"mshta32 foo.hta" may use mshta32 or mshta64 depending on what is associated with HTA
the same goes if "mshta64 foo.hta" is used
"cmd /C start foo.hta" would have the same affect.
Debugger
MS Script Editor (from Office XP/2003) for JS debugging in IE/HTA
Normally I would use the debugger keyword to initiate the launching of the debugger, however with IE9, it doesn't seem to do that anymore. I must launch the debugger first, attach to the mshta.exe process manually (only supports 32bit). Then everything appears to work fine!
EDIT:
With coworkers, different machine have exhibited different behaviors:
debugger keyword works fine
Connecting to MSHTA.EXE from the debugger doesn't work
I haven't yet found a silver bullet.
Try using 'Stop' statement. This should raise the debugger dialog
I had the same problem. Finally pieced together how to debug using Visual Studio from two sources
Turn on script debugging through Internet Explorer, as described here and here
Start up Visual Studio. Click on Debug -> Attach to Process
Run the .hta file and select the running process from the Attach to Process dialog
Related
First of all - this is all about the RTM Versions. And Windows 8 has some changes regarding the UAC, as we all learned from http://www.brianbondy.com/blog/id/140/, it cannot be disabled side-effect-free.
Now the problem starts:
Our main app requires elevated privileges (at least the server part). Debugging will only work when running VS in elevated mode, too. But when I'm starting a Silverlight Project in elevated mode of VS, the IE fired up for debugging is started as with normal privileges and debugging is not possible, too. To make things more complicated, we're not running solutions with all (700+) projects loaded, but do lot of our dev-stuff (compiling, starting, testing) in command line. Which needs to be elevated, too.
What is the correct configuration of UAC for this purpose: I want to be able to debug Silverlight applications running in Internet Explorer, Applications of any kind started by VS "F5", a server process started from commandline and (maybe) C#/XAML Metro-Apps?
In Windows 7 it was just disabling UAC and everything's fine. Now I feel like fighting against my own toolset and have a bad feeling about this.
And please - do not tell me that UAC is important and useful. I'm totally okay with it, but for a developer things are slightly different.
See this answer on Superuser:
The Only way I'm aware of which ensures it will always open as
Administrator (including when you open from file associations, jump
list etc) is:
Locate the devenv.exe file in Explorer eg mine is in C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\
Right-click devenv.exe and choose "Troubleshoot compatibility"
Select "Troubleshoot program"
Select "This program requires additional permissions"
You'll need to let it launch VS before it lets you click Next, but
then you're done.
EXTREMELY annoying that you can't just do this through the normal
properties dialog any more. It's like Microsoft are going out of their
way to ensure Windows 8 alienates as many people as possible...
Have you tried installing VSCommands and using the Always start Visual Studio with elevated permissions option? I'm not sure how this would function differently than restarting with elevated permissions but it can't hurt to try.
I ran into the same issues with the command line, debugging, and other things such as once you're running with elevated permissions you can no longer drag & drop files into Visual Studio, or open files associated with Visual Studio when it's set to always run with elevated permissions. This is why I've always disabled UAC.
In the end I just turned off UAC in the registry. I'm not missing out on anything by doing so. It would be nice to hear how Microsoft uses the Win8 + VS2012 combo internally after seeing how broken it feels.
A few days ago, the attach button in "Attach to process" dialogue became disabled in VS 2010 and VS 2008 likewise. At first I thought that it is just an extension I've installed in VS 2010 but then I noticed it is the same in VS 2008. The both VS's a re running in administrative mode and on Windows 7.
I looked around but I can't seem to find a solution to this.
If anybody has encountered an similar problem, a little help would do great.
Thanks upfront.
EDIT: Attached a picture of the dialogue!
Where it says
you should press 'Select' and ensure at least managed is ticked. (or choose automatic)
otherwise, the 'Attach' button will be disabled.
It could also be because there is already another debugger attached to the process - probably the currently running instance of Visual Studio but it may be another instance of Visual Studio, or another debugger entirely (such as WinDbg or a remote debugging session).
Check the "Processes" window (usually found under Debug -> Windows -> Processes) to see what processes Visual Studio is debugging.
Try stopping Visual Studio but don't close the process.
I have come across a weird situation under which Attach button was disabled. This was because of DebugDiag. Please refer the following thread for info.
I was trying to debug a windows service as described here and had the same issue. The solution was to run Visual Studio as Administrator and select to see processes from all users.
I'm creating an IE extension in C# using visual studio 2010. How do I go about debugging the extension whilst running it in Internet Explorer?
A few things are very striking:
This question is being asked a lot
Most answers, if not all, are incomplete or incorrect
So here it goes: In VS2010. perform the following:
Create your BHO project, a good starting point is: Demo IE Toolbar/BHO
Create a similar solution/project, Go to "Solution Explorer", Right Click your project or use Alt+Enter and go to "Properties":
Be sure the debug profile is selected:
We will need some post build events to register our assembly:
These are the different commands:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u "$(TargetName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /f /i "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /unregister /codebase "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /codebase "$(TargetPath)"
The order is important. First the assembly gets unregistered, then registered. The first time you run this, build will fail since these post-build events will fail. This is normal, the first time you build, there was no assembly registered and as such there is nothing to unregister. The second time you build, everything will work just fine. At this stage, after a successful, error-free build, manually starting IE should result in your BHO being visible:
Now we would also like to be able to just go and press F5, have the whole thing build, open IE and attach the debugger. Contrary to popular belief however, the VS 2010 debugger will not attach on its own, not even when defining "Start external program" in "Debug" (which in fact, is still necessary):
Doing so will start IE, your BHO should also run but breakpoints will not be hit.
To solve this we will use:
public virtual void SetSite(Object pUnkSite)
{
#if DEBUG
Debugger.Launch();
#endif
... Other code ...
}
This ensures that the debugger gets attached early on in the BHO lifecycle. Read about the nitty gritty details here.
Pressing F5 now will result in a few dialogs asking you which debugger to attach:
From thereon out it' s happy debugging:
I hope this helps!
EDIT
I recently was asked to bring some updates to a rather ancient BHO I wrote. Revisiting my own tutorial, I noticed some issues might come up when following it:
1) After quickly deploying a W7 machine with VS2010 (as released) I got a funky error when an attempt was made to attach the debugger:
I could resolve the issue by also installing VS2010 SP1 (as I used it originally) although I have no clue why this was happening.
2) Right now, when an attempt is made to attach the debugger, the instance of VS2010 holding my project is not in the list of available debuggers.
However, when I just cancel all dialogs and restart IE, the running instance is magically there and I can hit my breakpoints once again. The issue seems related to questions by others.
EDIT 2
The 2nd issue was solved after a full reboot, just as in the linked question.
Project + Properties, Debug tab. Select "Start external program", set it to c:\program files\internet explorer\iexplore.exe. You probably want to set the "Command line arguments" to the path of an HTML file that exercises your BHO.
Set a breakpoint on the code you want to debug. Internet Explorer will start running when you press F5. You'll see the breakpoint turning hollow, indicating that the breakpoint is not armed. As soon as IE loads your DLL, visible in the Output window, it will turn into a solid red. And the debugger automatically breaks when IE calls your code.
There is a registration step. Do always avoid using gacutil.exe, it does nothing but pollute the GAC on your machine. Always favor the "Register for COM interop" option in the IDE, the equivalent of running Regasm.exe with the /codebase option. No need for the GAC that way. Either way, VS must be running elevated to make these machine config changes, start it by right-clicking the shortcut and selecting "Run as Administrator".
I get the following JScript Debugger error when I click on the Start Debugging button in the Script tab of the Developer Tools (F12) window:
Unable to attach to the process. Another debugger might be attached to the process.
Closing all browser windows and launching ie again has no effect.Ending the process tree in Windows Task Manager and starting a new iexplore task has no effect.Hitting Shift-F5 when in the Developer Tools window has no effect.Rebooting the entire machine reveals how desperate I am and has no effect.Searching in Regedit's [HKEY_LOCAL_MACHINE\SOFTWARE] branch for "JITDebug" just reveals I don't know what the hell I'm looking for.
I find that I experience this problem when launching a site in debug mode from Visual Studio.
If you would like to use the debugger in Internet Explorer Developer Tools you would need to launch the site outside of Visual Studio.
I have a web application that I've always been able to run in Visual Studio and it debugs just fine (breakpoints work, I can pause execution, etc). Recently, the behavior changed suddenly, and a few things happen:
I start debugging, it lauches IE and loads the application, but after a few seconds (sometimes the page hasn't even displayed yet), Visual Studio acts as if debugging has stopped - I'm able to edit code in VS again, and the "Play" button on the toolbar is enabled. The application continues to run in the IE window just spawned, but I'm not attached to it
During this few seconds that VS is "debugging", because it detaches, my breakpoints show as hollow - as if I'm set to "Release" mode and they won't be hit. In fact, I have a breakpoint set in Page_Load, and it skips right by. I've checked, and I'm set to debug mode, though the compile mode dropdown is missing from my toolbar (I checked in the build properties to ensure I was in debug mode).
Can anybody shed some light here?
It turns out that this was actually a result of an upgrade to Windows Vista. VS wasn't being "Run as an Administrator", which caused it to lack the rights to attach to other processes for debugging. As a result, debugging would stop right after it started. Changing the VS shortcut to run as an administrator resolved this problem.
I've experienced samely looking behavior. The cause was in existence of several <system.web> sections (which is allowed by web.config schema). Visual Studio debugger (versions 2008 and 2010 were tested) looks in the first encountered section only. So if your <compilation debug="true"> tag is not in the first one, it thinks that there are no compilation.debug setting present and genrally tryes to add <compilation debug="true"> to the first <system.web>. In some cases VS2008 just silently procceds in this case. For example look here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=510354#details"
Have you installed anything else on the server / workstation recently?
We have a third party app that doesn't allow us to debug, w3wp.exe crashes immediately upon an attempt to debug.
I ran into something similar when I had placed some code in a constructor that was crashing. Exact same issues where the Debug would disconnect just after the application started up.
The short if it, check that you haven't configured a class constructor to run during web startup that is crashing...
Quick windows 7 update: I had to add "localhost" to my list of trusted sites to correct this issue...go figure.
Just a workaround for those (like me) for whom the above solutions do not work: After starting the app you wish to debug, go to Debug -> Attach to Process, and attach it to the process you want to debug. Works on my machine.
In my case, I faced this issue with Visual Studio 2019 and 2022 as well.
I tried upgrading/downgrading Visual Studio versions but nothing helped.
On debugging, I finally found the root cause and sharing it here to help others facing the same problem.
I was using Brave browser with Visual Studio and whenever I uploaded a file in my application, the Visual Studio debugging stopped automatically. The root cause of this issue is the feature in Visual Studio to stop debugging on closing the browser. With Brave browser Visual Studio feels like we have closed the browser on uploading the file. So to fix this issue I have turned of this setting as given here.
You can find this setting here
Tools > Options > Projects and Solutions > Web Projects > Stop debugger when browser window is closed, close browser when debugging stops
Just turn it off and everything should work fine.