Anyone

Thanks for the reply twig123. Yep, I remain puzzled as to what could be the issue. Have just tried installing the original OEM XP CD into the virtual machine, and that works fine. It's just the nLited version that doesn't work in the virtual setup. Also tried doing a new nLite, leaving in components that possibly could have affected it (e.g. the OOBE component, which I normally remove), and still no joy. Guess I'll keep going with the trial and error...

Hi. I've used numerous nLited versions of my (Dell OEM XP Pro) disc for a long time, with no problems. I just tried installing the nLited version onto a virtual machine (VirtualBox), to experiment with a few ideas. The intent was to have my regular nLited XP continue as the 'host' OS, and to install it on the 'guest' OS temporarily for experimentation purposes. I have been unable to get the nLited XP to install on the virtual machine...it freezes at the blue 'setup' screen. It works fine on a regular install, but not on this 'virtual' install. Could this be caused if the OEM XP is BIOS-locked, and therefore the virtual (guest OS) will not accept it because it doesn't recognise the 'hardware'?? If so, is there a work around to enable the nLited XP to be installed on the virtual machine? Many thanks in advance for any suggestions...

I had exactly the same issue as Cybertronic, when installing XP Pro (SP2) using nLite 1.3.5 for the first time this morning (have used previous versions many times without encountering this issue before), i.e. the absence of autoplay, the shell hardware service not running, and the same 1083 error msg in event viewer when trying to start that service. I determined that it was caused by an svchost error. The Shell Hardware Detection Service is configured to run under netsvs - but it was incorrectly listed in the relevant reg key. If you go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost then double-click on 'netsvcs', the relevant service name (ShellHWDetection) should be included in the list of services. In mine, 'ShellHWDetection' appeared at the end of the list, with a blank space between it and the other items. Odd. So anyway, by removing the blank gap, and inserting the name in it's proper place in the list, upon restarting Windows, Shell Hardware Detection service was running properly, the DVD drive was now recognised, and autoplay function was back! Haven't worked out yet what caused this to happen on this occasion, but hopefully this fix might help anyone who encounters the same problem...