My CRM Saturday presentation held in Melbourne, Australia on 29th July 2017. I presented about troubleshooting techniques that I use and also about my goto tools for troubleshooting.
5. Six stages of troubleshooting
1. That can't happen.
2. That doesn't happen on my machine.
3. That shouldn't happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?
http://www.68k.org/~jrc/old-blog/archives/000198.html
12. Chrome DevTools – Important shortcuts
Open DevTools CTRL + SHIFT + I
Open command menu CTRL + SHIFT + P
Go to source CTRL + P
Search across all sources CTRL + SHIFT + F
Toggle Breakpoint CTRL + B
Go to member CTRL + SHIFT + O
Evaluate selection in console CTRL + SHIFT + E
Pause/resume script execution F8
Step over next function call F10
Step into next function call F11
Next call frame CTRL + .
Previous call frame CTRL + ,
13. DevTools Demo
• Command Palette
• Locating the form JavaScript code directly
• Running adhoc JavaScript in context of the frame
• Blackboxing
• Pause on exceptions
• Workspace
20. FakeXrmEasy
• Opensource – (https://github.com/jordimontana82/fake-xrm-easy)
• Can be use for both unit tests and integration tests
• Supports CRM2015, CRM2016 and Dynamics 365 Customer Engagement
If you sharing your updates in Twitter, crmsaturday is the hashtag to use. So, if you any feedback to share or you would like to ping me about the talk, this is where you can contact me on Twitter, if I can’t answer you questions today.
This aim of this talk is to help developers to troubleshoot better. I will demonstrate some tools and techniques that can reduce the time it make the root cause analysis so that you can spend bulk of your time in fixing the issue.
I think Java was probably the first language that had error messages designed to confuse people rather than clarify. If you just leave out a semi colon, you would get 300 compile warnings, even for a simple Hello World.
Since there are lot of touch points in CRM, it is often confusing where the error is originating from: is it the framework version, is it permissions, is it something to do with permissions, plugin firing in the background, maybe the async service has stopped. There is so many possibilities. So this has to be approached in a methodical fashion. In order to do this you need to know some internals, as in how CRM does certain things, and what are the tools that are available to assist.
You might have heard about the five stages of grief which are Denial, Anger, Bargaining, Depression and Acceptance. This is some what similar to that model and it lists the stages the developer goes through before that actually fix the issue. In my experience 1 to 4 often takes the most time. Once the issue is identified the fix is quite easy or if it not easy you probably can always says that it will be fixed in the next update rollup or that it is not a defect but an undocumented feature.
This is troubleshooting 101. We first have to ascertain whether the bug was caused due to some change made by you or whether an external factor contributed to this behaviour. Without confirming this first we could be troubleshooting for days only to find out there as some Windows patch that caused some thing to break. For example there was a Windows patch released around March that messed up the form layout in CRM2011 when IE11 is used. So it is important to get this out the way first and do the due diligence first, so that we can focus our efforts into troubleshooting and resolving the issue.
Use FXB to do a fetch on import job against CRM Online. Do the same using Solution History Tool.
These are the areas I hope to cover in today session. Today I would be spending most of my time covering the first two. Server side sync is a bit tricky as it is a black box and you can’t really do a lot even if you discover any issues, but I can show the process of troubleshooting.
JavaScript: Don’t get me wrong. IE is a decent browser post IE9, but it still lags fairly when it comes to troubleshooting JavaScript. It can sometimes be the cure when it comes to dealing with legacy sites e.g. showModalDialog in Sharepoint, but from a debugging perspective it is like comparing metro to a bullet train. Both get you there, but one gets you there faster and in style.
This map from statcounter shows how quickly Chrome has been adopted by everyone. One reason could be how Google pushed it using their dominance is search, but as an end user it is really fast, and for a developer it has lot of debugging features that are not available in other browsers.
This is a Twitter poll result, that shows that console.log is still a really popular debugging method.
*AUDIENCE QUESTION*: How many use debugger; statement in code to start the debug session?
*FEW*: That good. *FOLLOW UP*: Do you all use Chrome? *IF ONLY FEW*: That’s good. I’ll show you some tricks that you would find useful.
You can pretty do these command using UI, but knowing the shortcuts saves time. This is a list of shortcuts that I use frequently during debugging. In terms the shortcuts like step out, step into and step over it is almost same as Visual Studio. So, if you are used to Visual Studio debugging this should be pretty familiar.
CRM2015 UR12 brought the multi-browser capability to CRM. When CRM2016 has changed is also where the form js code runs. It runs a separate frame called ClientApiWrapper. I guess this was a way to prevent people from directly accessing DOM elements in the form. I will be using Chrome Canary as it includes the latest and greatest features.
*WORKSPACE* drawback is that it loads the network resource when the page is refreshed and so it is not a replacement for the tools I am going to show next, which can load a local resource instead of a network resource.
When it comes to debugging JavaScript, you don’t necessarily have to deploy your JavaScript to CRM, to set the break points. You can use couple of these tools to sort of hijack the browser request for a network resource, and make it load a local resource. One significant advantage this has over Chrome workspace is that the changes are not lost during page reload.
Before plugin profiler came along, troubleshooting plugins or workflow assemblies was pretty hard. This is because you have to attach the debugger against the IIS process, if you are troubleshooting a plugin and against the async service if you are troubleshooting a workflow. This is not anyway possible with CRM Online as you don’t have access to the services, but regardless of CRM Online or CRM OnPrem attaching a debugger to IIS or async process in PROD is not really an option. Plus it also locks up the process for everyone else. I will shows couple of ways this can be done.
How many actually use profiler for debugging? I will probably run this through fast if most are familiar with this tool.
There are times when you have to troubleshoot issues that are application related and don’t involve any code. For e.g. during CRM install or org import or normal application use for that matter. What I am going to show you is the tool of last resort which is SysInternals ProcessMonitor. What is SysInternals Process Monitor? If you done any tracing in SQL Server, you would have used Profiler. This is pretty much something similar that shows the activities that are happening in the system like file access, registry access and process details.
I take this opportunity to thank the sponsors of CRM Saturday. Without their support an event at this scale would not be possible. I also thank MBS for providing the venue and all the volunteers for their help today.
