Where did my scripts go? How to debug JavaScript in CRM 2011 post-UR15

Chances are, you’ve recently read our Dynamics CRM 2011 Update Rollup 15 overview, read our post covering “what you need to know about UR11CU”, or read a partner blog article discussing UR15.  Each of these highlights how UR15 continues to enhance user experience, be it via the Outlook client or web browser.  As a result, specific changes focused on form load performance have a direct effect on how script libraries are served to the browser.  If you’ve already been developing/troubleshooting JavaScript in an environment updated to UR15, you may have noticed this effect.  Web Resources no longer show up individually by file name in your browser debugger (i.e. Internet Explorer’s F12 developer tools), rather they appear as dynamic scripts.  More on that to come, but first a little background.


In Update Rollup 12, changes were made so that JavaScript libraries linked to entity forms would be downloaded and processed without blocking the form.  Perceived form load performance increased, but not without a negative side-effect.  Script files weren’t guaranteed to load in a specified order, meaning dependencies between script libraries could lead to intermittent exceptions based on the actual load sequence.  For instance, if the jQuery library takes longer to load than your dependent JavaScript file, any calls referencing jQuery in your form onLoad event handler may throw an “Object Expected” error.

Enter Update Rollup 15 - A Fix:

To address this scenario, Update Rollup 15 again alters the way script library files are loaded to ensure a reliable behavior and address dependency constraints.  While script libraries now load in their intended order, the libraries are treated as dynamic script blocks making for an inconsistent debugging experience across browsers (debugging in Chrome? You won’t see them anywhere, although you can still do live debug by stepping into the functions or forcing a breakpoint in your code).

Form script load behavior by update:

  • CRM 2011 RTM through UR11: uses a method that guarantees script library load order and scripts are displayed as named scripts in browser debuggers.
  • UR12  through UR14: to increase perceived form load performance, introduces a non-blocking pattern to load custom form scripts which does not guarantee load sequence.  This change produced inconsistent behavior when dependencies exist between script libraries.  
  • UR15: uses a balanced approach, derived from the change introduced in UR12, that guarantees the script library load sequence as specified in the entity form definition.  This approach leverages synchronous XmlHttpRequests (XHR) and dynamic script blocks which in turn make browser debugging a challenge.

Now for what you’ve all been waiting for – how to debug entity form JavaScript libraries post-UR15:

Browser Debuggers: Dynamic script content is handled differently across the various browser debugging tools and even between versions.  In the case of Chrome’s debugging tools, you won’t see dynamic script content at all.  But have no fear!  We’ll address circumvent this roadblock by simply traversing up the call stack by one call.  Instead of breaking directly into your function, we’ll start from the point where CRM for script calls custom functions, then step into the custom function.  These calls originate from FormScript.js.aspx.

Note: Another option is to use the debugger statement – by placing it anywhere in a script file it will tell the browser to force a breakpoint and pull open your debugger (as long as script debugging is enabled).  This is not a desirable outcome for production code, so I suggest reserving this technique only for debugging in development environments.  The remainder of this article walks through how to debug without using a debugger' statement, which should be appropriate in all deployment scenarios. 

Debugging script libraries: Previous to UR15, you could simply launch the browser debugging tool, look for a named Web Resource file in the scripts list, and easily set a breakpoint to begin live debugging.  In UR15, the process changes slightly:

  • First open your browser debugger (for IE simply press the F12 key), then open the script debugger tab and make sure you’re actively debugging or attached .
  • Next, instead of looking for your Web Resource file in the document list, search for and select FormScript.js.aspx
    • TIP: This file may be nested under the edit.aspx file. In IE F12 developer tools, you may have to expand edit.aspx to find FormScript.js.aspx


  • Within the FormScript.js.aspx document, you will find your custom function call wrapped in an event handler.  For custom functions registered with the form onLoad event, look for the crmForm_window_onload_handler function.  All registered functions will be called, in sequence, within this wrapper function.  For custom functions registered for field onChange events, look for a wrapper function named [attributename]_onchange_handler.  Other form events will have similarly named event handler functions.
  • Set a breakpoint within FormScript.js.aspx on your function name.  Now when the event is fired, the breakpoint will be hit before your custom function is called, allowing you the opportunity to step into your function.
    • IMPORTANT: If you have more than one event on the form registered to the same function, there will be a separate handler per call!  You may have to set a breakpoint on all instances or use the wrapping function name to determine if the call pertains to your debugging scenario.


  • Trigger the event that you want to debug (onLoad, onChange, onSave, etc.).
  • When the breakpoint is hit, press the F11 key to step into your Web Resource code.  From here, you should be in familiar territory – continue debugging as necessary.


That’s it!  Hopefully, these tips have helped your post-UR15 script debugging efforts (and avoided an unnecessary headache).  If you have further technical questions about how to debug, post comments or click email blog author.  I am contemplating the creation of a video to walk through three or four common CRM debug scenarios.  If you would find this valuable, please provide that feedback.  As always, our team of Dynamics CRM PFE’s and Dynamics CRM Developer PFE’s are here to help, either remotely or onsite:

  • If you already have a Premier contract let your TAM know you want to work with a Dynamics CRM PFE and they’ll know where to find us
  • If you don’t have a Premier contract and you’re interested in Premier support and/or working directly with a PFE, contact us via our Premier Services contact page or reach out via the email blog author page.

Thanks for reading!
Sean McNellis

Follow me: @seanmcne

Microsoft Premier Field Engineer

Comments (21)

  1. ismail TUTUMLUER says:

    Nice post , I'm happy to MSCRM back to synchronous onLoad

  2. Toni Serrano says:

    Very good post,

    But since I install rollup 15 I have problems with all my javascripts. When I load a entity that have a javascript don't find my function.

    In FormScript.js.aspx there is my function, but browser (ie12) don't find.

    Any else have this problema? Is a rollup 15 error?

  3. R Tebar says:

    Great post and very useful information, thanks Sean. One question, what about Dynamics CRM Online? Are we going to see this new change in Orion?

  4. Scott Sewell says:

    The load order fix in UR15 is critical to us – glad to see it's been resolved.

    But this side-effect of UR15 freaked me out last week when I went to debug a form after applying the update – For a second, I thought my scripts were gone. 🙂

    Thanks for sharing the explanation and instructions.

  5. (and yes, the videos of the common debug scenarios would be helpful.)

  6. @Toni, try making sure you added the function and published all your changes and it will show up (if you just applied ur15 make sure you have rebooted and try flushing your cache just in case).  Finally, if all else fails use the "debugger" statement to force a breakpoint in your code.

    @Scott thanks for the comments and I am glad its working!

  7. @R Tebar, I am still looking into it for 2013 but I believe 2013 already respects proper ordering of scripts but did so using a slightly different approach/design.  I'll make sure to follow up when I am back in and have some time to test.  Thanks!

  8. @Toni, if you had found the function and ie11 didn't break, also make sure you've enabled debugging in the advanced ie options.  

  9. Ahmad says:

    Even with "debugger" statement you cannot debug after rollup 15. It does break the execution and you can launch your IDE. But as soon as your IDE launches, script execution continues and there is no debugging in Visual Studio. This is true even for CRM 2013 (new server, no upgrade). This is a huge problem for us now.

  10. @Ahmad,

    If you want to debug using the debugger directive you must have script debugging enabled and a debugger of some kind must be attached to handle the exception on behalf of IE – if VS or IE F12 tools are not attached your breakpoint won't be handled and it will appear as if there is a crash. There are two ways to make sure you are able to break when it hits the breakpoint one is using Visual Studio and the other is using IE's debugger (which is pretty awesome in IE9+).  Before you start you need to make sure you have script debugging enabled in IE's advanced options.

    1. Use Visual Studio: msdn.microsoft.com/…/z959x58c.aspx

    2. Use IE: msdn.microsoft.com/…/gg699336(v=vs.85).aspx

    Once I get back to work next week I'm going to try and find some time to record a screencast demo of each way – I'll do my best to get this done within 2-3 weeks.  Thanks for reading!


  11. Scott Durow says:

    I've finally got around to doing a deep dive on script loading with CRM2013 – here are my results – develop1.net/…/CRM-2013-Script-Loading-Deep-Dive.asp

    To answer the question about CRM 2013 – the scripts will not load in the order specified, they are downloaded and loaded in parallel.

  12. Reece Campbell says:

    Nice post with very useful information, thanks.

    The debugging scenarios video would be very useful too, cheers!

  13. Behnam Seidali says:

    The article was very useful as I was seriously looking for my JavaScript in debugger and finally found it and traced it after reading this post.

    Thanks a lot

  14. Jason Eldredge says:

    @Scott Durow – Can you please repost your link; it is returning a ror error.  Thanks!

    @Sean – Great Post!

  15. Greg says:

    @Jason Eldredge – Scott's link is just missing an "x" at the end of the URL:


  16. Davider says:

    Even with the Debugger statement, it DOES NOW work.

  17. ADeveloper says:

    Is anyone able to debug in Chrome or Firefox ?

    in Chrome i#m not able to find "FormScript.js.aspx",

    In Firefox i'm able to find FormScript.js.aspx but while debugging, Firefox is not able to find our custom code.

  18. Try using the debugger statement in your code, your debugger will automatically break when the 'debugger' statement is run.

  19. F12 step into - IE 8 says:

    I use IE 8.

    I tried the F12, the code attached to the breakpoint,

    but im not able to do F11(step into), I get the error "source code is not available for this location",

    F10 works fine.

    In IE 9 / 10 F11 works but I cant change the IE version.

    Is it related to the IE version or other settins? What can I do?

  20. @"F12 Step Into – IE8" – If you're able to use IE9/10/11 for debugging any problems that may help – though I understand how it may not work well. To Clarify my previous comment: You may have noticed in UR16 that the behavior has been reverted – we suggest you apply UR16 to inherit these changes.  If you absolutely cannot install UR16 there was a COD patch for UR15 (this COD is only valid if you have UR15 installed) but these are generally only distributed to customers that were blocked by this issue and could not wait for UR16.  Since this is really only to fix debugging, if you had to deploy the COD it may work best to only apply it in your lower dev environment – then move quickly to test and push UR16 so all environments would inherit this fix as well as the many other fixes UR16 adds.



  21. Stefan Schneider says:

    If you debug in Chrome, you can also just add a //# sourceURL=<filename> to your JS files to find it under (no domains) scripts in the Chrome DevTools

Skip to main content