Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
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.
Excellent, informative post, as always.
Great to see another posting after a long hiatus!
Although - I've been through this exercise myself; on the OTHER end of the stick - as a Group Policy "administrator" - because AutoPlay is actually located in several places in the registry (at least in 4.0 and 2000, I didn't wrangle so much with it in XP). You can turn it off in one place (like the HKCU setting) and have it overridden by the other setting. I would never have solved this one without Regmon, that's for damn sure.
In addition to the direct AutoPlay disable settings, there's the Policy settings. (I can't be specific, because I dealt with this about two years ago) - PLUS - there were certain third-party software installers that would go in and RE-ENABLE the damn AutoPlay setting on you. (and others that will politely turn it off; VMWare is one example).
Ah, those were the bad-old days. . .
I guess that your domain admin has seen the following post on Steve Riley's blog, applied the recommended NoDriveTypeAutorun 0x255 registry setting and deleted the "mountpoints2" key that stores the history of the USB sticks your Pc has ever seen.
Your administrator may have done this differently. He may have executed
%systemroot%\system32\reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\autorun.inf" /ve /d "@SYS:DoesNotExist" /f
"This hack tells Windows to treat AUTORUN.INF as if it were a configuration file from a pre-Windows 95 application. IniFileMapping is a key which tells Windows how to handle the .INI files which those applications typically used to store their configuration data (before the registry existed). In this case it says "whenever you have to handle a file called AUTORUN.INF, don't use the values from the file. You'll find alternative values at HKEY_LOCAL_MACHINE\SOFTWARE\DoesNotExist." And since that key, er, does not exist, it's as if AUTORUN.INF is completely empty, and so nothing autoruns, and nothing is added to the Explorer double-click action. Result: worms cannot get in - unless you start double-clicking executables to see what they do, in which case, you deserve to have your PC infected."
Here is the full story:
Nice catch. I'll come into your cubicle first thing on Monday and remove your Administrator rights. You will also have your coffee machine rights suspended for a week for laughing in the face of company policy.
You don't really want to set it to 0 - you want to set it to the default value of 0x91 (under XP at least - see MSKB 895108)
Otherwise it'll be enabled on floppy drives & network drives. In older versions of Windows (Windows 95) this meant that when you opened My Computer, you had to wait for it to scan these drives for autorun.inf in case they had an icon file entry - hardly ideal!
Not sure if this is still the case for XP but it might be.
Wow, someone who *wants* autoplay, which does both of the following IIRC:
Autodetecting new hardware and possible offering action choices....neat feature for some, distracting and annoying to others.
Autorunning arbitrary content....umm Security?
The settings of these two functions should be separate. :)
I've updated the post to note that on Vista, enabling AutoPlay the way that I did doesn't result in automatic execution of Autorun.inf, but instead configures the display of the AutoPlay dialog.
I think it's unfortunate that group policy settings are automatically applied without the user's knowledge or consent. I had no idea my registry settings were being modified by some external process. It would be helpful to present some kind of confirmation dialog, outlineing exactly what is changing on your computer.
Mark/Anyone that might know:
Today I was investigating ReadyBoost and SuperFetch and have some questions:
1) ProcMon doesn't report file activity on readyboost file on the flash drive, I can see flash drive blinking and I know it being modified. Any ideas why ?
2) Does readyboost file contains/mirrors parts of pagefile? If yes, I didn't find any documentation on this in MSDN but MVP's on newgroups have written that it is so. I would appreciate in depth document about it.
3) Which file contains the statististics/ranking about superfetch ? Is it in c:\windows\prefetch folder ?
Thanks a lot
Christopher Hill: "In older versions of Windows (Windows 95) this meant that when you opened My Computer, you had to wait for it to scan these drives for autorun.inf in case they had an icon file entry - hardly ideal!"
Shhhh. I was looking forward to "The Case of the Unexplained Network Pauses."
Regarding AutoPlay, why was the SHIFT override feature removed in Vista? It was very handy.
I too noticed lots of disk thrashing on my system and ReadyBoost drive. I posted some information on this a while back:
As you'll see in my post, the Vista performance tool does give you some detail about what's being written to an external drive, so you might look there to see what's being written to your flash drive.
Aaron Tiensivu found a post by Robert Hensing that indicates ReadyBoost regenerates its encryption key on every start and resume and rewrites a cache file containing the key. See Aaron's post here:
Robert's original post is here, though he's since recanted:
It looks to me like Robert was right the first time, but I'm certainly no Russinovich. I actually stopped using ReadyBoost because of the disk thrashing it causes on every resume from sleep. Lastly, I thought I read somewhere that Microsoft was changing the ReadyBoost encryption key regeneration feature for SP1, but I can't find where I originally read that.
Hope that helps.
Unfortunate: Acknowledgment is okay, but consent is not. Just imagine what corporate IT departments will think if they suddenly found Microsoft enables random staffs to bypass their restrictions...
I recently inserted a 2GB SD card on this computer for the first time, but the ReadyBoost tab of the drive's Properties dialog continued to show "Do not use this device" selected - or some text that indicated the drive was too small. I don't remember the specifics now, but the problem was that I had been using an SD card that didn't have enough capacity to support ReadyBoost. That eventually set an option to stop checking for ReadyBoost compatibility. I needed to manually override that option in the Properties dialog.
@unfortunate: most computers that are joined to a domain administered by others are not usually the personal property of the computer user, but are instead tools provided by an employer so that the user can do the job he or she is being paid to do. Such users should have no expectation to be told of every configuration change or policy setting unless they need to know it to do their jobs.