search cancel

Faulting application name: ScheduleProcessor.exe


Article ID: 257078


Updated On:


IT Management Suite


The customer recently upgraded from 8.6 RU2 to 8.6 RU3.

After the upgrade, he has noticed the following error entry on his Application Event logs:

Faulting application name: ScheduleProcessor.exe, version: 8.6.4286.0, time stamp: 0x62ea4407
Faulting module name: KERNELBASE.dll, version: 6.3.9600.20512, time stamp: 0x62cdfc6e
Exception code: 0xc0000142
Fault offset: 0x00000000000ed1b0
Faulting process id: 0x65fc
Faulting application start time: 0x01d908bba5445fc1
Faulting application path: C:\Program Files\Altiris\Notification Server\bin\ScheduleProcessor.exe
Faulting module path: KERNELBASE.dll
Report Id: e5bf7551-74ae-11ed-82b4-005056b91b36
Faulting package full name: 
Faulting package-relative application ID: 




Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: ScheduleProcessor.exe
P2: 8.6.4286.0
P3: 62ea4407
P5: 6.3.9600.20512
P6: 62cdfc6e
P7: c0000142
P8: 00000000000ed1b0

Attached files:

These files may be available here:

Analysis symbol: 
Rechecking for solution: 0
Report Id: e4f34d6f-74ae-11ed-82b4-005056b91b36
Report Status: 0
Hashed bucket: 
Cab Guid: %23


Since he was not sure if this error is something caused by the Symantec Management Platform (SMP), he tried running a repair on the SMP server but unfortunately, those are still there. He checked the application log, and a lot of those are still going on. He has no idea what kind of impact, if any, it's having on the platform as no one has reported any issues.

The NS logs shows no errors with ScheduleProcessor.exe. We can see that our schedules seems to be running just fine:

Schedule execution done: {10cebfd0-05e4-4a89-8d52-e512f93619f7}, async=False, time=00:00:02.4764454
Date: 12/5/2022 8:37:56 AM, Tick Count: 554072609 (6.09:54:32.6090000), Size: 335 B
Process: ScheduleProcessor (24568), Thread ID: 1, Module: ScheduleProcessor.exe
Priority: 16, Source: ScheduleProcessor


ITMS 8.6 RU3


Unknown. This issue has been reported to our Development team. We believe this issue is something environmental. 


Our Dev team investigated the provided dump files from this customer. The dump contains references that the "ScheduleProcessor" process fails during KERNEL32.DLL initialization.

They looked through the whole dump content, they didn't find any more suspicious things.

The only remaining c0000142 failure reason that they are aware of is so-called "desktop heap memory exhaustion", - some applications running in session 0 leak desktop heap memory, i.e. memory that stores windows data. Normally processes running under session 0 do not create windows since this session is not visible at all, but applications still can create windows and grab memory from the desktop heap. The desktop heap under session 0 is much smaller than for visible sessions, so not many windows can be created by applications running in session 0.

There are two ways to resolve this:

  1. Increase desktop heap size. Look here  WinFix: Error 0xC0000142 – Windows Task Scheduler fails to run in Batch Mode – YLNotes: Yunlong Notes
  2. Find services running under the SYSTEM account that allocated memory from the desktop heap. To do that check if there is any service running under the SYSTEM account that have an "Interactive" checkbox set. Try disabling those services temporarily, reboot the machine, and see if the problem is reproducible. Also check the processes that run under the SYSTEM account using Task Manager, identify each process that is not service, try disabling them, then reboot and see if the problem is reproducible.