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.

Comments (34)
  1. 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.

  2. John: I wasn’t aware of the autoplay repair wizard.

    Everyone: Thanks for the feedback. November and December were very busy months. I’ll try to keep the blog regularly fed and I have a bunch of posts planned.

  3. Who’s copying who? 🙂

  4. 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.

  5. WTF Chuck says:

    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.  🙂

  6. @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.

  7. Aaron Curley says:

    Excellent, informative post, as always.  

  8. Neil Prestemon says:

    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. . .

  9. Emin says:


    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%system32reg.exe add "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows  NTCurrentVersionIniFileMappingautorun.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_MACHINESOFTWAREDoesNotExist." 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:

  10. Mark's system administrator at Microsoft says:

    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.

  11. Christopher Hill says:

    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.

  12. unfortunate says:

    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.

  13. Koba says:

    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:windowsprefetch folder ?

    Thanks a lot

  14. Dave says:

    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."

  15. anonymous says:

    Regarding AutoPlay, why was the SHIFT override feature removed in Vista? It was very handy.

  16. Carl Campos says:


    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.

  17. Cheong says:

    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…

  18. o.s. says:

    It’s great to see you back Mark. Great post as usual. For a second there I thought you had decided to become a hermit and relocate to Antarctica 🙂

  19. John Dangerbrooks says:

    Hi, Mark.

    As a side note, I believe it’s worth mentioning that Microsoft AutoPlay Repair Wizard can help identifying such issues. It twice has came very handy in tight situations.

    By the way, long time, no see. I though my assassin suc— er — I mean, I thought, god forbid, something bad has happened to you. You really mustn’t leave your readers in dark for month 😉

  20. bobo says:

    I see you take care of many interesting cases. What about screen saver, that sometimes just doesn’t start, even it is set properly? Or power management system, which disables "Turn off monitor after…" whenever it likes.

    There are so many annoying things like this in Windows… or Explorer which hangs while searching for thumbnails for some files (video files but not only).

    Well, I hope all things you’ve found will be corrected in future fixes for Windows:)

  21. Rob says:

    Nice post. Its always good to hear how you tackle a process monitor dump, the sheer number of entries does make it difficult sometimes.

  22. xbprm says:

    Nice post. But some remarks require an answer

    1. "A local administrator is the master of the computer and is able to do anything they want"

    Exactly! And as long as there is no need no normal user should require these privileges. But sometimes it is necessary, just as this case shows. You wouldn’t be able to show the greatness of ReadyBoost!

    2. "just one more reason enterprises should strive to have their end users run as standard users"

    That’s just what MS wants us to be! Stupid end-users depending on the benevolence of allmighty companies/governments.

  23. Don Sutherland says:

    Great post as always.

    Hey, are you channeling SecurityMonkey over at ITT?

    This was totally done in his style.  LOL!!!

  24. james says:

    Aaron has a valid point, but it’s not always as simple as "the domain administrator’s word is final" – I suspect it’s the other way round in Mark’s case, and certainly is for me, in a university with partially devolved IT administration (authentication and standard user accounts are provided centrally by an automated process, but departmental staff are responsible for every aspect of the client machines – including purchasing, maintaining and supporting them). Indeed, a significant part of my time goes into poring over various logs and experimenting to get our departmental applications (such as AutoCAD and high-end finite element analysis tools) running properly from unprivileged student accounts. The per-computer registry settings are our own, as are the user policies applied, but the registry entries in HKCU are downloaded from a central server each logon.

    Presumably in this case the ‘no autorun’ policy was imposed for reasons which are no longer valid in Vista’s case; in a similar vein, there’s a prohibition on command-line apps which we inherit and have to override to allow an engineering application to run properly.

    (Being Novell-based means every user account is created automatically at login, then deleted at logout – which, of course, complicates things like ACLs as well…)

  25. tOM Trottier says:

    Why does Readyboost *assume* that the hard disk has better sequential access? Wouldn’t it be better to measure it in some idle moment?

    Faster flash these days means that newer flash memory like Sandisk’s Extreme IV (with sequential reads at 40MB/second+ – are twice as fast as my year-old laptop’s hard drive.

  26. james says:

    Tom: Testing both would certainly make sense; for the moment, it just assumes a certain speed of flash is enough to make a positive difference, but making it relative to the HDD (particularly for laptops); these days, you could have a desktop with mirrored 15kRPM disks (=> 500 seeks/second!) and a laptop with a single 4200 RPM drive, almost an order of magnitude slower for seek operations.

    Having said that, if the innards maintain a queue of read operations, automatically routing the smaller reads to flash where possible while the rest hits the disk, you should get the best of both worlds: the full throughput of both devices during heavy I/O, but never waiting for either device unnecessarily. A really fast desktop system would see most I/O going to disk, while the laptop would see the opposite – all without any magic numbers needed. Give or take a little CPU overhead, even the slowest flash device wouldn’t impair I/O significantly.

  27. Kurt das UberGeek says:

    This looked like a potential solution for an Autoplay issue (in XP) I have been dealing with for months. I had already run the AutoPlay Repair Wizard to no avail. So, I tried running thru this and got nowhere. It looks like I am missing 2 registry keys from:  HKLMSystemCCSEnum…!AlwaysEnable (Absent) <Not set> and HKLMSystemCCSEnum…!AlwaysDisable (Absent) <Not set>.  then I get a loving note at the bottom that says: Yup! You got problems, but I cannot fix them!  ANY ideas on something else I can try…anyone?  Buehler? Buehler?

  28. Taras says:

    Thanks for a good post. While I did not be deep in Vista, there some new thins for me explained. But one thins I do every time instaiilng OS for my own use: disable the service ShellHWDetection, because it’s the simliest way to disable annoying window every time I plug-in USB/SD drives (some times I do it very frequently)

  29. Mark Dean says:

    Autoplay, both the old behavior and the new Vista prompts are both annoying to me and must be disabled-and stay that way, especially on Windows systems. I’ve noticed Autoplay has even crept into Linux desktops (but it is much easier to disable-I hate the concept of the registry, give me plain text configuration files any day of the week). So it is funny to me to find someone who actually *wants* it to be enabled.

  30. Paulo Bral™ says:

    Very informative and helpful, thank you very much!

  31. Norman Diamond says:

    Here are a few more cases of missing and/or garbage AutoPlay.

    In a Windows XP system which is not joined to a domain, AutoPlay is random.  Even on an old-fashioned conventional read-only CD-ROM such as from MSDN, containing a valid autorun.inf file, XP will select one of four possibilities at random:

    (1) run the autorun.

    (2) prompt the user.

    (3) do nothing, but include an autorun context menu entry when the user right-clicks the icon for the drive.

    (4) do nothing, and do not include an autorun context menu entry when the user right-clicks the icon for the drive.

    Well, the above is for CD-ROMs.  Now let’s consider other media.

    Nice screenshot of some of the registry values from page

    Now, does anyone know how to make it work?  For example, every time I attach a 500GB USB hard drive, XP KNOWS that I want it to search for pictures to print and songs to play, and after it finishes searching 500GB it presents a menu for me to select "do nothing".  XP KNOWS this, it really knows, so that’s why it ignores (or some random times even doesn’t offer) an option to always select the same choice every time.  XP knows I don’t really want to do nothing.  What useful purpose could a 500GB hard drive have other than to be searched every time I attach it?

    Then there’s USB memory keys.  In many parts of the world, a lot of people now still can’t afford their own computer but they can afford their own USB memory sticks.  They save their own files and viruses themselves.  When they need to use a computer, they borrow one wherever they can, and exchange viruses with those on the borrowed computer.  In the old days with floppies you had to boot or execute a program in order to share viruses, but with modern efficiency in today’s world autorun.inf takes care of it for you automatically.  I’m glad Vista stopped doing that automatically, but that’s not going to help much.  During the 10 years that it will take to turn Vista into a useable OS, XP is going to continue automating virus epidemics.

  32. Alnoor JiwNI says:

    I tried this technique to deny "SYSTEM" access to some of the policy setting in XP and works like a charm.  I needed to override the Group Policy of "Classic Start Menu".  I have tried the same in Vista Enterprise SP1 but it does not seem to work.  The access seems to get reset to FULL Control everytime the system is re-starte.   Any  update on this situaiton would be greatly appreciated.

  33. anonymous says:

    Hey for those whose issue has not been solved by reading this try uninstalling softwares that cause the problem ie:

    Real Player 10, Nero 7 etc.

    The autoplay dialog was mising from my pc and the right click menu as well. But on reading wikipedia’s article,I decided on uninstalling Real Player and voilá it works!!!!!!

  34. basit says:

    As usual Mark  does a great job, he is truly father of windows ,I assume Marks unix background makes him special about understanding core windows concepts..

    Mark You are just great!!!

Comments are closed.

Skip to main content