Just for tracking I’m posting my very first practice test exam attempt results below (results I’ve got more or less expected for attempt taken without any preparation at all):
You can expect some related posts about this exam and related topics as I go through exam preparation process.
Just a short note on how to collect process dump including LeakTrack information.
Download latest version of Microsoft Debug Diagnostic Tool, at the moment it is Debug Diagnostic Tool v2 Update 3 and install it going through an installation wizard steps as shown below:
Once installation wizard completes, download ProcDump and unzip it on the server where you going to collect dump file. Next, run DebugDiag 2 Collection:
Cancel out initial “Select Rule Type” dialog:
Navigate to Processes tab select process for which you need to collect LeakTrack, right click on it and select Monitor For Leaks:
Click Yes in “Do you want to enable ‘Service Mode’ and continue” pop up:
You will see confirmation that monitoring for leak has started:
Now let it run and wait till the process you monitor use up large amount of RAM and take dump using procdump.exe, you can see some hints on the command line syntax below:
Once dump taken you can stop monitoring for leaks and close Debug Diagnostic tool:
After following steps above your process memory dump should contain LeakTrack information. You can tell that by the dump file size – if you take a dump without enabling Monitor For Leaks option in Debug Diagnostic Tool at the same time you will see that your dump file size will be smaller if compared with one which you take while running Monitor For Leaks .
Just a short explanation of how to take process dump using CDB.
First you need to get Debugging Tools for Windows. To get Debugging Tools as a standalone tool set you can just download Windows SDK and during installation select Debugging Tools for Windows:
Once Debugging tools for Windows are downloaded and installed
you can find cdb.exe in the following location – C:\Program Files (x86)\Windows
Kits\10\Debuggers\x64 (note that number
highlighted in bold may vary depending on SDK version installed – in my case it
is 10, and you obviously have cdb.exe for different platforms – x86/x64 etc. –
just navigate to appropriate subfolder of Debuggers folder).
To take dump launch CMD in elevated mode, switch directory to CDB location and execute cdb -p <PROCESS PID> to take crash dump (remember that PID information can be found in Task Manager or retrieved with PowerShell using Get-Process “%ProcessName%” | select -expand id):
At this stage CDB is attached to process and closing this
CMD window will terminate process you are attached to. Once CDB is loaded type
in the following commands:
..loadby sos clr
You will receive
“No export Thread found” error – it can be ignored, and some more commands needs
to be executed. First run !StopOnException
-create System.StackOverflowException it may not work from the first attempt,
just re-run it once again until you see confirmation that breakpoint was
breakpoint is set type gn and wait
for process crash:
process crashed the following commands have to be executed:
.dump /ma /u C:\dumps\process.dmp
gn until you get “there is no debugee” message. Your dump will be written in
the location you specified above (C:\dumps\process.dmp).
You may see the following error message on attempt to create new web application using SharePoint 2013 CA UI:
Error message says: “Invalid URI: The hostname could not be parsed“, at the same time creation of web application using PowerShell may work just fine. This error can be caused by the fact that you have asterisk (“*”) as a value of Host name property in bindings of one of your existing web applications. Removing asterisk and leaving host name blank should resolve this issue.
Some time ago I wrote a blog post where I explained how to change SQL Server instance collation for installed SQL server instance (see “Changing SQL collation for deployed instance without reinstall (almost)“). That post contained some scripting bits to detect installed SQL Server version and navigate to appropriate setup directory to facilitate collation change process. Recently I had a bit of time to consolidate these bits of PowerShell into one script which detects installed SQL Server version and changes directory to appropriate setup folder. Here you have it: