Thanks for your help. Glad you reproduced problem. Final piece of
information.
When setting up the Guest account, I erroneously set the Fax driver as
my default printer. Then I tried to print a test page. I got a
message saying the Shell Hardware Detection Service was not started.
I found my error and corrected the printer setting. Not knowing
exactly what Shell Hardware Detection Service was I ignored it. With
my current insight I thought that information might be of help to you.
Lou
Well, I've completed my analysis of the problem. It's a pity I'm not from
Microsoft, because only they can fix the problem.
First some background:
As you've guessed, Windows Autoplay is implemented by the Shell Hardware
Detection Service. This service allow Windows to detect changes to
hardware, such as when you plug in a printer, or a memory flash card or a
usb device, or (in our case) inserting a CD. Upon inserting the CD, the
shell hardware detection tells explorer: "Hey, somebody inserted a cd,
what do you want me to do about it?"
Explorer, then looks at the cd to find its contents (is it music? is it
pictures? Or something else?). Explorer then tells the Detection service
what kind of cd it is (eg. music). The Detection service then looks up the
"AutoPlayHandlers" registry to find out what to do for Music cds. Now the
computer knows how to run music cds, so all that's left to do is for
explorer to run it.
For all of this to work, Explorer and the Shell Hardware Detection Service
must be able to freely communicate with each other.
So why does Guest fail??
Have you noticed that when you try to enter services.msc as Guest, you get
an Access Denied message? The key to this entire problem is that Guest
does not belong to the "NT_AUTHORITY\Authenticated Users" group. When
WinXP entered the beta stages (back in 2001), Microsoft removed the Guest
account from the "Authenticated Users" group, for some rather complicated
reasons (hint: Nimda).
To communicate with the Shell Hardware Detection, a program needs to
invisibly open up services.msc, scroll down to the service, check if it's
started, then start communicating with it.
Unfortunately, you can only open up services.msc if you are an
"Authenticated User", which Guest is not. And there is NO way to let non-
Authenticated Users access services.msc (that's as quoted by Microsoft).
So this is what happens instead. You insert the CD, the shell hardware
detection service tells Explorer that a new cd was inserted. Explorer
finds out what's on the CD (eg. music). Then tries to talk back to Shell
Hardware Detection.
Here, XP discovers that Explorer is on Guest, and Guests aren't allowed to
talk to Services, thus blocking the message. So explorer is left there
without a reply, so Explorer says: "Hmm, autoplay doesn't seem to be
running, but then what am I supposed to be doing with this CD?" Explorer
then falls back to its default (Win95) behaviour of just opening up the CD
folder.
This looks like it's more than you needed to know.
Enough Background, So how do we fix it?
The only workaround I can find is to turn Guest into a normal user.
Although that's quite easy for XP Pro (lusrmgr.msc), it's not exactly easy
for XP Home. Maybe "control userpasswords2" can help.
The only other solution is to do what you are already doing (use a
different account). These are the only two workarounds, no solution is
available (That is, until MS provides a way to change the ACLs on SCM).
--
------------------------------------------------------------------------
oshah
Control Panel -> System -> Advanced -> Error Reporting -> Choose Programs
-> Do not report errors for these programs:
Acrobat.exe
waol.exe
------------------------------------------------------------------------