Visual Studio JavaScript debugging extremely slow - javascript

I am having the strangest problem debugging JavaScript in Internet Explorer in Visual Studio.
If I set a breakpoint in JavaScript code and run the (ASP.NET MVC) project in debug mode, I hit the break point fine. But shortly after that, while on the breakpoint, pretty much my whole computer locks up for 10-30 seconds. During this time I can move the mouse pointer, but not interact with anything. If I click on things eventually the computer starts to beep.
After the 10-30 seconds is up everything is back to normal.
Debugging worked fine up until a couple of days ago. The same behavior is shown by different ASP.NET MVC projects.
I am running Internet Explorer 10 and Visual Studio 2012 on Windows 8 Enterprise 64 bit.
I have no third party antivirus (Only Windows Defender). I do not have intellitrace. I have only a single breakpoint, all others are deleted. I have tried deleting my .suo file.

My browser (ff) locks up on me when a script on a website is taking too long to run typically. It then throws a stop script prompt. The fact that you can replicate it across three computers makes sense if it's the same erroneous script causing the lock up. I doubt it'll matter if you try it on a win 7 box, win xp, but those are obvious tests if you're thinking sys configuration as a cause. Also, try setting your breakpoint earlier in the script to tell what/when is locking up.
On a different note, I've always debugged javascript in firefox with firebug with great success.

I had this same problem and it turned out it was Intellisense. Intellisense chokes on large Javascript files. The slowdowns would happen even when I wasn't doing something that required Intellisense.
I ended up splitting them out and referencing the other files with:
/// <reference path="/scripts/<other>.js" />
This allowed autocomplete to work across files and prevented the lockups.

Related

How to run a JS debug session using MS Visual Studio 2022?

Could someone reply with the exact steps to rub a debug session using MS Visual Studio, for a Html/Javascript WebPage, using the Chrome Browser?
I am really confused between LiveServer, Launch Chrome, and the Run and Debug control on the left side of the IDE. I seem to get it to work at times, but wind up with multiple Chrome Browsers displayed. Really would like to know the correct process is.
Thanks so much.

How do I ensure my script file isn't cached when debugging a VS MVC website?

I came across a problem today where the only way for the web program I am developing showed the most recent copy of a modified script was to reboot the machine. It is a file bundled in the master layout page, in a script bundle. I tried CTRL-F5 and deleted all files (I think) in Internet Options of IE11 to ensure it wasn't using the cached copy, but that was not sufficient.
I then suspected the cause is related to the fact I am using the VS Development server in VS2010. I tried killing WebDev.WebServer40.exe, hypothesizing it was caching it there, but that was not it either. I made the test as basic as modifying the entire contents of the script file to be a single alert() message, which never appeared, until I rebooted the machine.
I've seen suggestions to add args to the file when referencing it, or rename it each build, but clearly that's not productive when running many iterations in new development. I am wondering if there's perhaps a Visual Studio or Internet Explorer option here that guarantees to load the un-cached file each build? Is IE also possibly caching this info in some other memory space I need to be aware of too? thanks
EDIT:
Ok, it turns out the root cause of the problem was a post-build step modifying the script files I was working on. Rebooting was therefore a coincidental fix. As always, blame the writer. :). However, I have seen this problem occur many times in the past, genuinely, and am still curious if there's browser settings available (with specifics) that ensure scripts (and CSS files) are never cached, in development.
Disable the browser cache. Accessed through the debugger or developer tools (usually F12).
Here are some examples:
Chrome
Firefox
IE11

Breakpoints not hit in javascript files in Visual Studio

I am experiencing some weird behaviors when debugging my MVC Web Application. Some days I experience these issues, but other days everything works fine.
The breakpoints in my javascript files are not getting hit. I get the dreaded "The breakpoint will not currently be hit. No symbols have been loaded for this document." error.
The debugger will detach from the process without me clicking the Stop Debugging button.
I have tried everything I can think of including:
Refreshing the page in IE to force the browser to get the latest version of the javascript files.
Clean / Rebuild the application in Visual Studio
Close / Reopen Visual Studio
Delete all files from bin and obj folders and rebuild
Cleaned up all old sites from my IIS Express applicationhost.config file
Installed VS2013 Update 4
Deleted / Reinstalled VS2013
Removed / Added IE11
Installed VS2015. Same behavior as VS2013
Deleted all local project files and performed a "Get Latest" from TFS
I can manually attach the debugger to an iexplore process and then I'm able to debug that specific file, but it seems like there is a different iexplore instance for each javascript file. I end up having to guess which one to use for each javascript file. To top it off, the debugger keeps detaching in the middle of me trying to find the right process to attach to. It is nearly impossible, and definitely not feasible to try and debug this way.
Our solution is in TFS, we're using IS Express and the three other developers on our team have none of the problems I have. We all have the exact same hardware.
Another clue that might help is that we are using the OWIN functionality to connect to ACS for security. If I bypass authentication through OWIN / ACS I can step into the javascript. This, however, creates other problems since the code is expecting me to be authenticated. This is not an acceptable workaround and, again, the other developers on the team are using OWIN/ACS and do not have any problems.
I'm extremely frustrated and at a loss for how to go about figuring our what is wrong with my environment. Any help will be greatly appreciated.

why is this page crashing iOS?

http://bit.ly/Z7YPj7
It works fine on the desktop everywhere, and also on Android. But on the iPhone Simulator, the culprit appears to be in the file: js/the-anim36.js (which queues a whole bunch of Raphael SVG animations).
I'm monkeying around with Safari 6's "Develop" menu, which can now log info from the XCodes's iOS Simulator, which i downloaded and fired up. But I'm getting absolutely nothing in the javascript console, and a hard crash in the simulator each and every time I open the html file. I have to "Reset Content and Settings" each time I try to open the file. I'm frankly lost here, admittedly a novice at debugging in general (and also probably spoiled by Chrome.) Any pointers on what's possibly going on here would be very appreciated.
You can run out of memory really fast on iOS. Run it through the Chrome profiler and see what you're memory usage looks like. I bet it's using > 10mb of ram. In which case you're probably toast!
Check out this informative article, that claims after about 6mb of ram, you will crash mobile safari:
http://cubiq.org/testing-memory-usage-on-mobile-safari
I observe that when I open that page my laptop fan run on high. The thing is consuming a lot of CPU (and likely a lot of RAM) and may simply be exceeding the allowable resource limits on iOS. If not running out of RAM it could be causing the foreground process to run too long, triggering the logic that cancels "looping" apps.

Can I get the Internet Explorer debugger to break into long-running JavaScript code?

I have a page that has a byzantine amount of JavaScript code running. In Internet Explorer only, and only version 8, I get a long-script warning that I can reliably reproduce. I suspect it is event handlers triggering themselves in an infinite loop.
The developer tools are limping horribly under the weight of the script running, but I do seem to be able to get the log to tell me what line of script it was executing when I aborted, but it is inevitably some of the deep plumbing of the ExtJS code we use, and I can't tell where it is in my stack of code.
A way of seeing the call stack would work, but preferably I'd like to be able to just break into the debugger when I get the long script warning so I can just step through the stack.
There is a similar question posted, but the answers given were for a not-the-right-tool, or the not terribly helpful advice to eliminate half my code at a time on a binary hunt for the infinite loop. If my code were simple enough that I could do that, it probably wouldn't have gotten the infinite loop in the first place. If I could reproduce the problem in Firebug, I'd probably be a lot happier too.
Here is what I would do:
Go to http://www.microsoft.com/whdc/devtools/debugging/default.mspx and install the Debugging Tools for Windows. You want to run WinDBG when this is installed.
Follow the steps outlined at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a to setup the symbol server connection and have the symbols automatically downloaded to your local drive (c:\websymbols -- or whatever).
Run IEXPLORE.EXE under WinDBG. The help file should give you assistance in doing this if necessary. You need a couple of commands once you get Internet Explorer running and such. First, go ahead and get that large script going.
Break into the debugger (CTRL-SCROLLLOCK to break).
a. Do a LN to "list nearest" to get the DLL files that are loaded. Hopefully, you'll have JSCRIPT.DLL loaded in memory.
b. Type .reload /f to force the reloading of all of the symbols. This will take a while. Now, after this is done, type LN again and you should see that the proper JSCRIPT.PDB has been downloaded to your system in the symbols directory you setup earlier.
Depending on what you want to do, you may need to restart the debugger, but you can do this: After the initial break on WINDBG load, you can type "sxe ld jscript.dll" and it will break when jscript.dll loads.
This is the tricky part, because once this loads, you don't have the code for jscript.dll, but you have the proper symbols (if they are not loaded, then reload them with .reload /f). You can view the functions available by typing "x!jscript" and you'll get a full list of all of the functions and variables.
Pick one, set a break point, and then you should be able to track what is happening to your script.
If nothing else is accomplished, by using the .reload /f process, you can get the appropriate jscript.pdb files loaded on your system. It's possible you could use these in conjunction with Visual Studio to do additional debugging in that manner, but I'm not so sure how well that will work.
I've run in to this before and have had some luck with enabling the developer tools along with Visual Studio. When an error is encountered the page loading is halted, and I could then load up Visual Studio to see the specific line causing the trouble.
This site has some information on using Visual Studio along with the Internet Explorer debugger: Using Visual Studio to Debug JavaScript in IE

Categories

Resources