I deployed the current patches to a small group of lab machines and at least one, maybe more was rebooted by the ampagent even though I have it set to prompt in the same schedule we always use with no changes to it. The event log has the data below. I need to deploy to our end users today. Anyone know why the Ampagent would force a reboot like this? Or better yet, is this something that may happen to many more machines?

We're at 6.2 with all fixes. Agents are 6.2.1025. Windows 7 x64bit client.

The process C:\Program Files (x86)\Dell\KACE\AMPAgent.exe (COMPNAME) has initiated the restart of computer COMPNAMEon behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown
 Reason Code: 0x80070000
 Shutdown Type: restart

EDIT: Could this be caused by a machine running low on disk space? I just noticed the first machine that reported this is 96.6% full.

Reboot options are as below. Same settings we always use.


3 Comments   [ + ] Show Comments


  • I just had two systems reboot tonight. Both systems have the The process C:\Program Files (x86)\Dell\KACE\AMPAgent.exe (COMPNAME) has initiated the restart of computer COMPNAMEon behalf of user NT AUTHORITY\SYSTEM for the following reason: Legacy API shutdown.
    Patching is not running on my system because the hard drive is full and all the systems are in downloading status. Also the schedule that these tow systems are in has a reboot later option set after prompting the user for a reboot. From the time the command shows up to when it rebooted is like 20 minutes.
  • Seeing this as well on x64 boxes only. Disk space is not an issue. Did it in December AND January. 32 bit boxes are fine. Only started doing this with the 6.2.1025 agent.
    • I haven't seen this recur at my site since it first happened last month (in December). I'm fairly confident my issue was related to disk space on the local drives of the machines that experienced it. If I could get Kace's reporting to work right, then I'll have a report schedule to notify us of low disk space. If it's not one thing....
  • Just got this back from my support case on this: This issue has been verified as a defect and raised as KA-1162. This will be evaluated by our Product team for inclusion in a future release of 6.3 K1000 Systems Management Appliance.

    A list of “Resolved Issues” is published in the product Release Notes accompanying new releases that can be referenced to identify if a fix for this defect has been implemented. Product Release Notes are available in the “release notes and guides” area of our Support Portal at software.dell.com/support"
    • Wow. They acknowledged that unwanted auto reboots are occurring on clients and plan to evaluate it for resolution in a future release. Why am I not stunned... People are losing work and money due to this issue and Kace doesn't consider it to be worthy of more attention. Typical.

      Did they label it as a problem with "patching" or with "disk space" or any other moniker beyond the call number KA-1162?
Please log in to comment


From what I remember if you have ANY reboot options other than NO REBOOT it will eventually reboot the machine. With the options you have above it will show 5 prompts at 5 minute intervals and then at the last prompt it will reboot.

The way KACE has this set up is as follows...
NO REBOOT = PC will not reboot.
Force Reboot = No prompts, PC just reboots
Prompt User = Prompt shown. Ability to snooze reboot but eventually the PC will reboot.
Answered 12/29/2014 by: h2opolo25
Red Belt

Please log in to comment
Based on what the Help / User Guide says, your machines shouldn't be rebooting with that patch schedule. That said, I'm inclined to agree with h2opolo25 on this. Here is a snapshot of the Help below.

If the reboot was delayed at each prompt then it would've rebooted, based on what I'm reading below. But you said these were lab machines so they would've been left untouched yes?

Answered 12/29/2014 by: getElementById
Second Degree Blue Belt

  • Thank you both. These machines (in our little world at my office) are referred to as lab machines with regard to patching. I send a patch run to lab machines that nobody uses with a forced reboot and if those machines are good, then I send patches some of our IT staff machines which is what this one was. One of our staff members reported that her machine prompted to reboot, but she didn't click yes or no and it rebooted that same morning. But her reboot occurred prior the timer running through all cycles.

    ANSWER: Her C: drive was 99% full. That's the only difference I found between her and the others that reported no problem.

    Today, some of our non IT staff returned from vacation and one found they had patched but their machine was too slow to use. This machine is also 99% full. Maybe it's just coincidence, but I'm a bit concerned that the patch run is not deleting expanded files. Hard to say if the files I found were left because the patch run failed to delete or if they failed to be deleted because the drive ran out of space for other reasons of low space (user files). Both users have profiles in the 30GB range with other large chunks of data that should be elsewhere.

    I'm fairly certain this was a case of low disk space prior to the patch run, but if anyone else has seen a patch run eat up available disk space, please let me know.

    Much appreciated to all for the suggestions and advice.
    • That is odd. I could see the job failing if there wasn't enough disk space but that doesn't explain the rebooting problem. After reading your comment here I went and looked on my own machine and found 1.5g of un-deleted items! But, most of the patches were recent (last Monday) so maybe it does delete on the next run? I'm not sure... Back to the original topic of reboot, you said in your OP that you needed to push to the end users that same day. Did you do that already? [Edit]: and did any machines reboot that shouldn't have?
      • No reports from anyone else regarding anything related to this patch run. I did push our staggared runs and all machines that have been online have patched. I suspect, but could be wrong that one of the two users was being pretty active either deleting files or breaking connections so that could have contributed to the reboots.

        I do think there's some extra files laying around that should've been deleted, but I haven't determined with certainty that these files are patch related.
Please log in to comment
You need to examine one or two of the affected machines with very low available disk space to find out exactly what is eating up disk space.  I have seen a machine with 15Gb of Office service packs repeatedly downloaded because there was an error in the local Office source files preventing the service pack installing correctly.  This was in the %TEMP% folder.  Patch runs frequently fail to delete files, so you need to check both the user and system %TEMP% locations and all the other usual download locations that can fill up.
Answered 12/29/2014 by: EdT
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity