Windows 10 Client 0.11.4 Windows Service

  • Hi,
    i´ve seen a bug in the Fogservice of the new Fog Client.
    When the image Process is completed, the Client go for his Local Windows account, there, i see the Service “Fog Service” was not started. I searched in the Event Viewer and there it says that there was an Timeout (30 seconds) for Starting the Fog Service was reached. This only happens on slow Clients with an HDD, at Clients with SSD this is no Problem, because they are fast enough.
    Maybe you should fork the Start of the Service and go directly to the end of the ON Startup Method.

    I hope this helps and sorry for that bad English from a German guy;).


  • Senior Developer

    v0.11.5 of the client prevents premature startups of the service. You will still need to disable the client before syprepping and restart the computer when sysprep is complete though (as described in the updated FOG Client wiki article).

  • Senior Developer

    @Joe-Schmitt Do you think it’s safe to solve this thread?

  • Senior Developer

    The v0.11.5 release candidate should fix this issue. More testing needs to occur before I mark this as solved though.

  • Moderator

    @RLane You can’t expect support for the new FOG Client without giving the senior developer of the new FOG Client a log, which he needs to give support.

  • Senior Developer

    Yes I understand, I need to see if any entries are being made in the fog.log on the failed start.

  • @Joe-Schmitt There isn’t because the service is not starting until a manual reboot. In event viewer, it shows that the service failed to start after 3000 ms or something, failed twice like this.

    Good news though… works well on an SSD. Any machine with a 7200 HDD, it doesn’t start the service in time. I haven’t had a computer fail yet with an SSD.

  • Senior Developer

    @RLane are there any entries in fog.log?

  • @Joe-Schmitt I did. I’ve tried with the reboot - didn’t work. I’ve tried with automatic-delay - didn’t work either.

  • Senior Developer

    Can you update your setup complete to restart as described in the updated wiki article?

  • @Joe-Schmitt Hi,
    In this Textfile you see the Hardware of two diffrent machines, the Bluechip with the SSD work with the auto and delayed auto option, the HP 6300 Pro Clients with the WD Hdd only working with the delayed-auto option.
    0_1469777655120_Spec 112 113.rtf

    sc config FOGService start= delayed-auto
    net start FOGService

    Windows 10 education 64 bit
    Office 2016 32 bit
    Eclipse IDE
    All updates of Office and Windows are installed, also it is the current Version of the other Software.

  • @Joe-Schmitt I will do it tomorrow when im at work.

  • @Max-Kern said in Windows 10 Client 0.11.4 Windows Service:

    @RLane Hi,
    Yes this worked for me very well on about 60 machines.
    I put the delayed-auto into the SetupComplete an deactivate the Service like it says the wiki.

    Well but i like that it works with any machine i try from vm to high end workstation.
    some days ago the wiki was itself talking about delayed auto but this has changed and that for a good reason.

    Well if you only using one special type of hardware you sure could stay with delayed auto and your good to go.

    Read this i think he knows what he’s talking about ;)

    Regards X23

  • Senior Developer

    I will look into this when I get a chance. Could you describe in detail the hardware that has this issue and the OS config (e.g. if its sysprep please provide the unattend and setup complete) also the exact OS info. I need to figure out how to replicate this on my vms.

  • @RLane Hi,
    Yes this worked for me very well on about 60 machines.
    I put the delayed-auto into the SetupComplete an deactivate the Service like it says the wiki.

  • @x23piracy I’m not using OEM. I’m using a KMS key - Windows 10 x64 for Education. I had no issue with the same setupcomplete.cmd and unattend file with 0.11.2. After upgrading to the RC’s, it began to give me issues.

  • @RLane you should not use delayed-auto if so there is a race condition for breaking the image when deploying, for some machines you could have luck and for some maybe you will get an error.

    In short when using OEM you can’t use SetupComplete.cmd without calling it by unattend.xml section firstlogoncommands.
    If you are not using OEM you can use SetupComplete.cmd as normal but stay away from delayed auto.

    @Tom-Elliott @Joe-Schmitt Could someone add this information to the wiki?
    If OEM call setupcomplete.cmd via unattend.xml section firstlogoncommands
    if no OEM use Setupcomplete.cmd as normal

    Check here:

    Regards X23

  • Cross posting here:

    Same issue I’m having. You marked it as solved, I’m assuming you just set the service to start as delayed prior to sysprepping and that solved it?

  • @Joe-Schmitt with the delayed-auto option it works fine for the slow machiens, maybe there is a Problem with the configuration of the Service Controller (but why this is the only service and why on the other clients it work?). I think the Fog Services is start very early and waiting for dependence (i dont know which, so i cant say anything to it) maybe a network or somthing else, and at startup this dependence first must initialize befor it can go on, that would explain why this is working with delayed start of the service, because all dependence are loaded, this also will explain why it will start if the machine has loaded the gui and all other stuff.

  • Senior Developer

    @Max-Kern that also indicates an incorrect service configuration. I’m not denying that it could be a coding issue, but your issue fits a service configuration issue in every regard. None of the service controller stall prevention code base is being initialized, none of the eager JIT compiler response time minimizers are running, the offloaded worker threads aren’t kicking in, and the IPC bus isn’t initializing. This all indicates that the service controller is misbehaving.

Log in to reply

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.