You were upgrading your SMP Server.
After the upgrade, you noticed the following error entry on your 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
P4: KERNELBASE.dll
P5: 6.3.9600.20512
P6: 62cdfc6e
P7: c0000142
P8: 00000000000ed1b0
P9:
P10:
Attached files:
C:\Windows\Temp\WERECC5.tmp.appcompat.txt
C:\Windows\Temp\WERFC17.tmp.WERInternalMetadata.xml
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ScheduleProcesso_1d3c5e781d5f8b8e286aef599aa0a130fca0b71d_a210a83f_cab_45dffe67\memory.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ScheduleProcesso_1d3c5e781d5f8b8e286aef599aa0a130fca0b71d_a210a83f_cab_45dffe67\triagedump.dmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ScheduleProcesso_1d3c5e781d5f8b8e286aef599aa0a130fca0b71d_a210a83f_cab_45dffe67
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: