Visual Studio is a great tool. It is easy to miss some useful features. XSLT debugger does not want to miss. Below, you can see the debugger is running, because xslt conversion is used in some XML. (Please forgive me XSLT used in the example meaningless. I have a long period of time without the opportunity to use XSLT.)
XSLT debugging is very interesting to me, because most of it is managed debugger. XSLT compiler is msil, for providing managed debugger breakpoints and single-step execution capabilities. Open the "Modules" window you can see that. In the last column, you will see that the process is called Microsoft.XSLDebugProxy.exe hosting process, and there will be some modules loaded name, such as System.Xml.Xsl.CompiledQuery.1. All debugger windows are as expected: callstack, locals, immediate, threads, modules. You can see examples of my meaningless in the call stack below:
however! Go callstack window and right-click to get the context menu. There will be an item called Show External Code of. Select this option, you can see a lot of hidden content before the callstack window. Gray frame is because the assembly does not have debugging information (pdb file), which is why these frames were previously marked as "external source". Compiled query frame is hidden because XSLT compiler to place them on a property, they are not interested in telling the debugger. Using the expanded view, you can now see the compiled query and scheduling its code.
However, while this is interesting, but it is unlikely to help you understand XSLT errors. However, one of the "local" window seems to be more useful window, it can help you see what happens when the application transformation.
