The Case of the Missing AutoPlay

 I’ve been presenting talks on Windows Vista kernel changes since TechEd US in the summer of 2006 and one of the features I cover in the session is ReadyBoost, a write-through disk caching technology that can potentially improve system performance by leveraging flash media as a disk cache. I explain ReadyBoost in depth in my TechNet Magazine article, “Inside the Windows Vista Kernel: Part 2”, but the basic idea is that, since flash has significantly better random access latency than disk, ReadyBoost intercepts disk accesses and directs random-access reads to its cache when the cache holds the data, but sends sequential access to directly to the disk. During my presentation, I insert a USB key, whereupon Windows displays an AutoPlay dialog that includes an option to configure the device for ReadyBoost caching:

The first time I gave the talk, the demonstration went flawlessly, but in subsequent deliveries I didn’t get the AutoPlay experience. I would notice the lack of AutoPlay as I ran through the demonstrations before a session, but was always pressed for time and so couldn’t investigate. As a workaround, I would manual open the properties dialog of the device’s volume after insertion to show the ReadyBoost page that’s displayed when you click on the “Speed up my system” link on the AutoPlay dialog.

The last time I presented the session, at TechEd/ITforum in Barcelona in November, I had some extra time beforehand so I decided to find out why AutoPlay wasn’t working. The first thing I did was to check the AutoPlay settings, which you configure in the AutoPlay section of the Control Panel’s Hardware and Sound page. Some of the entries were set to “Ask me every time”, which shouldn’t have had any effect, and even after resetting to the defaults, AutoPlay still didn’t work:

At this point I had to look under the hood at an insertion’s associated Registry and file system activity to see if that would reveal the reason why Explorer wasn’t honoring the Control Panel’s AutoPlay settings. I ran Process Monitor, configured the filter to include Explorer’s Registry operations, and re-inserted the key. Then I stopped the capture and looked at what Process Monitor had collected.

A staggering 22,000 events meant that scanning through the trace event-by-event would take hours and there were no obvious error codes to search for, so I had to think of some keyword that might lead me to the relevant lines. I first searched for “autoplay”, but came up empty. I knew that Explorer looks for a file named Autorun.inf in the root directory of removable media volumes, which can contain pointers to an icon to show for the volume and an executable that launches when the user double-clicks on the volume, so I next searched for “autorun”. The first hit didn’t look interesting because it referred to the volume’s mount-point GUID, information that Windows generates dynamically when it notices a new volume:

The next hits were just a few entries later and all referred to values that store Group Policy settings:

The queries of the first two locations resulted in NAME NOT FOUND errors, indicating that the policies weren’t defined, but a query of HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun was successful. Process Monitor showed the value Explorer had read in the Details column:

I didn’t know how to interpret a setting of 255, so I executed a Web search for “nodrivetypeautorun” and found a page in the Windows 2000 Resource Kit that describes the value as a bitmask specifying which device types have AutoPlay disabled. A value of 255 decimal (0xFF hexadecimal) disables AutoPlay on all devices:

I used Process Monitor’s Jump-To functionality to launch Regedit and navigate directly to the value, opened the value editor, and changed the setting to 0 to enable AutoPlay on all devices. Next I had to test the change. I removed and reinserted the key and, to my satisfaction, the AutoPlay dialog appeared. Note that on Windows Vista, AutoPlay no longer means "automatically execute what's in Autorun.inf", but rather, "show me my options", so I wasn't introcuding a potential security issue.

The case was almost closed, but I had one detail to wrap up. AutoPlay was disabled on my system by the Group Policy configuration of the Microsoft domain to which the system is joined. That explained why the demonstration had worked for the first few times: my first deliveries of the session were before I had joined Microsoft. It also meant that the value would get restored to its previous setting the next time I logged on and Group Policy reapplied the domain’s configuration. If I happened to logon before the session the demonstration would break again.

There’s no way to opt out of Group Policy updates short of removing the system from the domain or never connecting to the domain. However, because I have local administrative rights, I realized that I could prevent Group Policy from changing the value by setting the permissions on the policy’s key such that Group Policy wouldn’t have permission to do so. Group Policy processing occurs in the Local System account, so I opened Regedit’s permissions editor and removed write access for the Local System account:

I was now confident that the demonstration would work for my current delivery of the Vista Kernel Changes session, as well as any future ones, and I closed the case. Besides highlighting Process Monitor’s usefulness for uncovering a root cause, this example also illustrates the power of local administrative rights. A local administrator is the master of the computer and is able to do anything they want, including circumventing domain policies, something I covered in a previous blog post, and that's just one more reason enterprises should strive to have their end users run as standard users.