Unavoidable reboot window RRS feed

  • Question

  • We have worked out our WES7 Image and after it is set up and on a machine it works great. Our problem is, we burn this image to a new drive and place it on a machine, and on the first boot up it always asks for a restart now later prompt because it found new devices. Now, I understand that each drive is a different device in some respects. All our machines are made with the same hardware components, but none of them have a keyboard. After the second boot, this appears to be ok with exception. If the drive is sent to a customer and their machine has the drive in a different sata port, it will again say it needs to restart. The other is when our customers make drive copies so they have spares. They can still only run as many as we have given them security codes for, but if they replace a failed drive with an untested, un-ever-booted copy, the restart prompt is there.

    We are running a custom shell which regulates when it allows our user application to run after all prep work is done on the boot. Exit our app and our shell handles all configuration needed for our machine. Our final app is also a full screen app and depending on the user app, can be any number of different resolutions. When it full screens it opens and once it is, that is when the dreaded Microsoft Windows, You must restart your computer to apply these changes dialog box pops up, minimizing the full screen app. The touch screen is still locked into the full screen app so you cannot do anything with the dialog and unless you have a keyboard which isn't there, useless machine.

    We have looked and scoured the web but found nothing related to identifying this new device state prior to our shell opening the user full screen app. In the boot process, I would have thought there was some api call or registry flag or anything that we could check and depending upon that result, force the reboot restart or allow the shell to start the user app.

    We have already tried searching and watching the processes as they start. The dialog is created through umpnpmgr.dll connected to a svchost and ultimately uses newdev.dll and something to do with dinotify.exe. This looked like a possible method to watch for and then decide ourselves when to reboot, by looking for the process involved. Problem is that chronologically, our shell has already finished its configuration and prep work and already started the full screen user app, then the process comes up. By that time, forcing the reboot won't help because the reboot causes corruption in our data because the full screen user app is in its own setup steps.

    Ok, the question, anyone out there have an idea or method we can employ that allows us to check for the new device state or stable device state to allow us to either do the reboot or move on to starting our user app? We could increase the wait time but we have seen it take as long as 5 minutes before this dialog box pops and throws the system into a mess from a user perspective and that is too long.

    Thursday, February 14, 2013 9:43 PM

All replies

  • I think this one is "persistalldeviceinstalls" assuming that your  golden image machine and your destinations are identical, that should get rid of it.

    Look in 

    product > blah > Pnpsysprep_amd64

    turn these both on.

    • "donotcleanup..."
    • "persistalldevice..."


    Friday, February 15, 2013 2:45 AM
  • Strang you are running into this problem. Most cloned images to the same hardware shouldn't have this happen. The different SATA ports and sometimes different USB ports can kick off the hardware wizard. Make sure that you have PersistAllDevices set to true in the Sysprep unattend file.

    Do you have FBWF or EWF in the image?

    -Sean / / Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

    Friday, February 15, 2013 2:46 AM
  • Going to check the PersistAllDeviceces, no FBWF or EWF at the moment, still looking at changing our software around to be more FBWF and EWF friendly


    Friday, February 15, 2013 6:01 PM
  • I recommended using FBWF as the next embedded OS will have a new filter that uses the write-through capability.

    -Sean / / Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

    Friday, February 15, 2013 9:03 PM