none
Win8 "respecialize" is there any documentation? Is there any way to control and/or disable this feature? RRS feed

  • Question

  • Background: we migrate VMs from a server running hyper-v to client systems running xen (or other virtualization technology, but not, for now, hyper-v.) When these migrated VMs first start after their migration they have a different device model from the one they were running on under hyper-v. (Basically they initially run in an emulated legacy pc hardware environment.) We then do a background install of various drivers that will enable full virtualization, including of course disk and net drivers. This all works fine from XP through Win7. Win8 appears to have introduced a new and as far as I can tell completely undocumented feature that "Respecializes" the OS image using sysprep, if for some reason some agent has decided that this needs to be done.

    This "respecialization" can be observed in setupapi.dev.log:

    [Boot Session: 2013/02/18 12:26:44.489]

    >>>  [Sysprep Respecialize - {70d59888-940b-3c47-bde9-28dc9b667dd1}]
    >>>  Section start 2013/02/18 12:29:26.657
         set: BIOS Release Date: 02/13/2013
         set: BIOS Vendor: Xen
         set: BIOS Version: 4.0.4
         set: System Family: 
         set: System Manufacturer: Xen
         set: System Product Name: HVM domU
         set: System SKU: 
         set: System Version: 4.0.4
    <<<  Section end 2013/02/18 12:31:03.549
    <<<  [Exit status: SUCCESS]

    Also, when device install goes through a "Restarting Devices" operation:

         dvi:                          Needs Respecialize: Hardware configuration {a7c9a307-5521-4313-99f6-98e156e74ee3} (Id = 0).

    To get to the point of this question, SOMETIMES, respecialization appears to interfere with background device installation such that devnodes do not get started. This is a disaster for what we are trying to do, which is to instantiate a virtualized PCI device that in turn needs to instantiate a new system bus that has an HBA and bootable disks associated with it. Our pci driver will sometimes get loaded during install, but no device add operation occurs and consequently it never manages to perform its bootstrapping operations.

    So - where is the documentation? How is the decision to "respecialize" made (it is not done every time we perform these migrations, only sometimes.) Can respecialization be disabled? Why does respecialization sometimes interfere with normal device install operations? Can that event be detected?

    On edit: there is one mention I've found under windows to go here on technet: http://technet.microsoft.com/en-us/library/jj592680.aspx

    But that is not exactly helpful.


    Mark Roddy Windows Driver and OS consultant www.hollistech.com


    Tuesday, February 19, 2013 2:21 PM
    Moderator

All replies

  • Can you please give more detail on how you do the background install of various drivers?  Do you know specifically what is causing the devnodes to sometimes not get started?  Respecialize should not significantly alter device installation behavior so you are potentially having a problem completely unrelated to respecialize that might happen even if you could turn respecialize off.

    Tuesday, February 19, 2013 6:57 PM
  • Basically we are running a VM image in the background (essentially headless) after migrating the image to a new platform in order to install the core (i.e. boot) drivers for the hypervisor on the new platform. The install has to be completely automated, no user intervention. I have very limited capabilities to diagnose problems specific to this process (no debugging, no user access, no display etc.) - pretty much all I can do is collect log files and similar types of data. So I don't know why devnodes aren't being started. Most of the time they are. In fact the same identical VM image, bit for bit identical, can succeed one time and fail the next. What I do know is that failure is always associated with respecialize being triggered. Really all I want to do is have mechanism to prevent respecialize from starting in the first place, it is completely inappropriate to what we are doing.

    Mark Roddy Windows Driver and OS consultant www.hollistech.com

    Tuesday, February 19, 2013 9:00 PM
    Moderator
  • What methods or APIs are you using to add the drivers and install them on devices?  Do the %windir%\inf\setupapi.* files show any errors (lines that start with !!!)?  What are the differences between the new platform in the cases you don't see respecialize vs you do?  For example, in one case has the VM been booted on that machine before so it doesn't need to install any devices vs in the other case it hasn't booted on that machine before so it has to install most devices in order to boot?

    There is no mechanism to prevent respecialize from starting.

    Tuesday, February 19, 2013 10:45 PM
  • Q: What methods? A: Standard documented supported methods for signed drivers. This all works from XP through Win7.

    Q: errors in setupapi.dev.inf? A: no. The only difference is that the devnode for the PCI device that is the root devnode for our hypervisor virtual bus never gets started.

    Q: what are the differences between success and failure? A: We "publish" and then "deploy" shared VM images to multiple clients. The "published" images are always exactly the same when they are deployed on a client and have never been run on that client, which is why we have to intervene and install boot drivers for the hypervisor on the client. The same identical image, never having run on the client, can succeed one time and fail the next. Also after a failure we throw away the VHD disk and start over again with a clean image. There is no accumulated history. Respecialize does not happen every time.

    "There is no mechanism to prevent respecialize from starting". Well sure there is, it just probably isn't documented or supported. But really I'd settle for having documentation for what "respecialize" is doing and how the decision is made to respecialize.


    Mark Roddy Windows Driver and OS consultant www.hollistech.com


    Wednesday, February 20, 2013 2:03 PM
    Moderator
  • Are you able to share the methods you use?  Different documented methods have different behaviors. 

    Do you see sections in the setupapi.dev.log file that indicate your PCI device was installed/reinstalled?  Does it indicate that a restart of the device was skipped for some reason?

    If you are moving the image to a new machine and you are not seeing respecialize, then windows thinks it has booted on that machine before.  You can find some very minimal information about this detection in the video at http://channel9.msdn.com/events/BUILD/BUILD2011/HW-245T (skip to 18:23).  However, respecialize in general is not documented.  While that video is talking about the Windows To Go scenario, the detection that the image is on a machine it has not seen before is a generic windows feature that exists outside of Windows To Go.  In addition to that, the operation that caused the "needs respecialize" log line you mentioned will not cause respecialize to happen on that boot, but may cause respecialize to happen the next time you boot on a certain different machine that it thinks it has seen before.

    Thursday, February 21, 2013 2:02 AM