My org has been using a K2000 to deploy scripted Win7 x64 images for a few years and have recently started to notice an issue, where after the "Windows  setup" screen, the deployment process will hang at "Set Engine Run Key" for anywhere from 30 minutes to a few hours, and sometimes it hangs here indefinitely.  During this time, all I see on the client is a black screen with a mouse cursor.

We are running K2000 version 3.7.120251 and are doing a scripted installation using Win7 x64 media.

Since deploying to the same PC will sometimes complete and sometimes not, that leads me to discount a driver issue (if a driver were missing, then one would think the deployment would never work).

At the black screen where the system is hanging, I can press shift + f10 to open a command prompt, and I have verified that the system has network connectivity at this point.  The contents of c:\windows\panther are available at this link.  I'm not sure what these are used for, but I've seen others include them in their posts requesting assistance.

If I open task manager while the system is on the black screen, I can see that svchost.exe is doing something, but as to what it's doing, i'm not sure and I don't know how to figure that out:


Based on the presence of wusa.exe, I'm guessing that the system is applying Windows Updates.

Any clue as to why this behavior would start suddenly without having made changes to the scripted install, or how we can prevent Windows Updates from running at this point?
0 Comments   [ - ] Hide Comments


Please log in to comment

Answer this question or Comment on this question for clarity


There are still many various possibilities, however the path you mention of c:\windows\panther is used to host the unattend.xml file that is used for image deployments. If the unattend.xml file has the option to update windows patches enabled then it could be applying these from the point the image was captured to the current release of patches.

Usually the set engine run key would indicate that the network driver may not be the best matched driver to use - could there be lots of extra drivers in the KBE build which may have the systems picking different network drivers for the install process?
Answered 03/24/2016 by: TheAustinDave
Brown Belt

  • Thanks for your comment.

    As mentioned, I wouldn't think that consecutive deployments to the same hardware would be picking different NIC drivers each time. If no changes are being made, one would presume that the driver selection / installation process would be identical in every deployment, or are you saying that is not the case?

    I checked the link you provided, but it seems to be for image deployment so I'm not sure it's relevant for scripted installations?
  • Follow up - I checked the unattend.xml file and couldn't seem to find any reference to updates. Do you know specifically where I'd find that?

    Based off of the link you shared, it seems the issue is that the KACE engine is supposed to be running and reporting in with the K2000. If I manually run c:\Kace\Engine\KaceEngine.exe from a command prompt while the deployment is stalled at a black screen, that gets it going again and the post install tasks pick up as they're supposed to, so the issue seems to be that for some reason the KaceEngine.exe file isn't running like it's supposed to be.

    In the unattend.xml file, I see the following:

    <SynchronousCommand wcm:action="add">
    <Description>KACE Engine</Description>

    So it looks as though KaceEngine.exe is supposed to get kicked off the first time the system boots, but my guess is that when the system is hanging at the black screen, it isn't progressing that far, so I'm assuming tthat's what I need to track down.
Please log in to comment
The scripted installs also have the option to enable the windows updates during the install, should be able to verify if that is the case by going into the scripted install and selecting the show option on the deployment details page.
Setup Configuration: (Hidden)Show
Answered 03/24/2016 by: TheAustinDave
Brown Belt

  • Ah, I see. The <ProtectYourPC> setting was set to 1, so I'm going to try setting it to 3 (disabled) and see what that does for me. Thanks!
Please log in to comment