Last month we had a VBUG Newcastle meeting for IT Pros with two great presentations (it would’ve been three but we’ve had to re-schedule one – more news on that when I have it). The first presentation was from Microsoft Premier Field Engineer, Richard Diver, called Implementing the “Black Box” – Performance Monitoring and Analysis for proactive and reactive support, server baselining and capacity planning and covered a number of tools…
If you haven’t been using them, you should take a look into:
- The Windows Sysinternals tools, which can be run without downloading, via Sysinternals Live by mapping a drive direct to \\live.sysinternals.com\tools\
- IT Pros should especially look to Process Explorer to give a more comprehensive view of what’s happening on a system. You can even replace Windows Task Manager permenantly with it.
- Many people who have opted to stay with XP until perhaps an upgrade to Windows 7 may not have seen the newer features of Performance Monitor (perfmon) and the Reliability Monitor (which was introduced in Vista and Server 2008).
- Windows 7’s fabulous Problem Steps Recorder, which allows users to easily record screenshots of the issues that they’re having to send to the support teams (or to let you see exactly what the relative that always calls you up for tech support is doing wrong!).
One of the questions that came out of the audience, regarding Problem Steps Recorder, was “can you run it from the command line?” At the time I think there were a few chuckles as people thought about how it might be used as a tool for spying, but after a while I started to think about the possibilities of automating around PSR…
Out of the box, if you want to use Problem Steps Recorder, you have to tell a user (let’s imagine they’re on the phone) to open the Start menu and type “psr” or “psr.exe” or some part of “Record steps to reproduce a problem”, which is how it is officially surfaced in Windows 7. You then have to tell them to start recording, go through the steps that are causing them the problem, stop recording, name and save the PSR output file somewhere and perhaps email it to you.
I thought, what if I could have them launch something that would automatically decide on a file name (based on the username, machine name and time), start recording and pop up a cut down UI that just had a button that would stop recording and save the file to a network share, or potentially email it straight to me. I know that’s not really saving a lot of steps, and they aren’t especially complicated steps anyway, but I’m a great believer in technology being as invisible as possible, so if something can be tailored to suit a particular environment, to make life a little bit easier for specific users, then I think it’s worth doing.
It turns out that there are command line parameters for Problem Steps Recorder, but they aren’t all that easy to find. Once I’ve written my script I’ll post it here, but in the meantime, here’s the help for psr.exe:
psr.exe [/start |/stop][/output <fullfilepath>] [/sc (0|1)] [/maxsc <value>]
[/sketch (0|1)] [/slides (0|1)] [/gui (o|1)]
[/arcetl (0|1)] [/arcxml (0|1)] [/arcmht (0|1)]
[/stopevent <eventname>] [/maxlogsize <value>] [/recordpid <pid>]
/start :Start Recording. (Outputpath flag SHOULD be specified)
/stop :Stop Recording.
/sc :Capture screenshots for recorded steps.
/maxsc :Maximum number of recent screen captures.
/maxlogsize :Maximum log file size (in MB) before wrapping occurs.
/gui :Display control GUI.
/arcetl :Include raw ETW file in archive output.
/arcxml :Include MHT file in archive output.
/recordpid :Record all actions associated with given PID.
/sketch :Sketch UI if no screenshot was saved.
/slides :Create slide show HTML pages.
/output :Store output of record session in given path.
/stopevent :Event to signal after output files are generated.
PSR Usage Examples:
psr.exe /start /output fullfilepath.zip /sc1 /gui 0 /record <PID>
/stopevent <eventname> /arcetl 1
psr.exe /start /output fullfilepath.xml /gui 0 /recordpid <PID>
psr.exe /start /output fullfilepath.xml /gui 0 /sc 1 /maxsc <number>
/maxlogsize <value> /stopevent <eventname>
1. Output path should include a directory path (e.g. ‘.\file.xml’).
2. Output file can either be a ZIP file or XML file
3. Can’t specify /arcxml /arcetl /arcmht /sc etc. if output is not a ZIP file.
I’m pleased to say that Richard enjoyed presenting to the group as much as we enjoyed his presentation, so he’s coming back to do another session on 25th November on Advanced Troubleshooting with Sysinternals Tools. I’ll post more details shortly.