Today’s post is actually from my personal troubleshooting experiences last week. I have been playing with Windows 7 quite a bit recently. I upgraded my primary work system, my laptop and my home system to the Windows 7 build that was released at PDC in October . Last weekend, I decided to upgrade my home system to a newer daily build of Windows 7. This would actually be the second build-to-build upgrade on my home system. The first one went very smoothly, and so I was optimistic that this new upgrade would be equally painless. I decided to try something a little bit different with this upgrade however. Rather than using physical media or a copy of the DVD files expanded to my hard drive, I thought I’d mount a copy of the .ISO file to a virtual DVD drive and try performing the upgrade in that fashion.
Now, Windows7 doesn’t have a built in utility to mount a .ISO file and present it as a DVD drive, but there are a number of useful utilities that are available. I opted to choose an internal utility (still being tested) that was recommended by someone on our Windows 7 Beta team. I downloaded the utility and the .ISO file for the build I wanted to install. After configuring the utility which presented the virtual DVD Drive as Drive R:, I mounted the .ISO file and ran the setup.exe file to start the upgrade.
The upgrade itself was, as hoped, fairly painless. A little less than two hours after I kicked off the upgrade, I was back at my desktop and ready to test applications. I’ll be perfectly honest here – you would have thought that the first couple of applications I tested would have been the updated build of Internet Explorer 8 , Microsoft Outlook 2007, or the updated Windows Media Center. Wrong on all counts. The first application I tested was World of Warcraft , the second application I tested was my Zune software. After all, this is my home machine!
No problems with World of Warcraft (phew!), but definitely a problem with the Zune software. None of the DRM-protected songs from the Zune Marketplace would play. Each DRM-protected song would display a small yellow exclamation mark next to it. When I clicked on the exclamation mark to see what the error message was, this is what was displayed.
Uh-oh. Well, I know I didn’t launch the Zune software from within WinDBG or another debugger, so this message seems somewhat odd. I clicked the link for web help – alas, no real help there either. OK then, this might actually require some troubleshooting. The first thing I did was search around for any Zune command line switches to see if there was an option to launch Zune in debug mode. I checked for any application compatibility fixes being applied to the software via the registry ( HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers ) – no luck there either. An interesting problem to be sure.
A couple of web searches on the error message (“ Running this process under a debugger while using DRM content is not allowed ”) yielded a few results, most of which mentioned a tool that I knew was not installed on my system. But … I did find a post on one of the TechNet forums that finally pointed me in the right direction. The post’s author indicated that he had been messing about with the boot settings on his Windows Vista system to change the number of processors used during boot. And that’s when it struck me.
As part of the installation for the utility that mounted the .ISO, I recall seeing that the Boot Configuration Data Store had been modified. I went back to check the installation batch file and sure enough …
bcdedit /debug on
bcdedit /set testsigning on
The first switch enables the kernel debugger for the specified boot loader and the second switch enabled the OS to load test-signed kernel mode code – the driver for the virtual DVD drive. For 64-bit versions of Windows Vista (and later versions of Windows), the kernel-mode code signing policy requires that all kernel-mode code have a digital signature. The OS relies on the digital signatures of these components to increase the safety and stability of the platform.
This code signing policy is in addition to the Plug and Play device installation signing requirements that affect the installation of a device driver. Driver developers / publishers must comply with both the kernel-mode code signing requirement for loading a kernel-mode driver and the PnP device installation signing requirements for installing a driver. The tool’s developer had created a test-signed driver file to enable the driver to install and had also opted to enable kernel-mode debugging to facilitate troubleshooting the driver.
Armed with this information, a quick check in MSCONFIG.EXE (I know, I could have just run BCDEDIT.EXE from an elevated command prompt) revealed that the debug switch was still on.
Unchecking the box and rebooting the system took only a couple of minutes … and voila! All was well again. Just to be on the safe side, I did go back in and run the BCDEDIT /DEBUG OFF command however. Although the resolution itself was simple, finding (or in my case remembering) what had caused the problem took a little bit of reasonably basic troubleshooting, a little luck with internet searching and a little bit of patience.
So, the point of this post wasn’t necessarily to show you how to troubleshoot a Zune issue – but rather to demonstrate that what sometimes seem like innocuous changes made for a good reason have unintended consequences. In this case, no harm done, and a simple resolution. However – in the enterprise – where hundreds (or thousands) of clients may be affected by a simple change … thoroughly testing (and documenting) your changes is absolutely invaluable. Until next time …
Additional Resources:
- MSDN: Kernel-Mode Code Signing Policy (Windows Vista and Later)
- MSDN: Plug and Play (PnP) device installation signing requirements
- MSDN: BCD Boot Options Reference
- MSDN: BCDEDIT /debug
- MSDN: TESTSIGNING Boot Configuration Option
| Share this post : |
|
|
|
|
|
|
|
|