Error Handling Change in 2015A?

[Chris.Kubiak]

Our organization runs SCCM for systems management.  Part of that system includes PC refresh (renaming\app reinstallation) processes.  In that process our PC names change and one of the tasks we perform in our script is a loop that checks the status of the SCCM service and triggers a DDR (data discovery record) via WMI then a check to see if SCCM has the new updated PC name.  I just recently upgraded my Winbatch+Compiler to 2015A from 2013C and noticed a peculiarity.  The same code that works as expected when compiled in 2013C doesn't work the same way when using 2015A. 

In particular:
DDRServiceLocal = GetObject("winmgmts:\\.\root\ccm:SMS_Client")
LogText = "Triggering DDR"
GoSub Write2Log
DDRServiceLocal.TriggerSchedule("{00000000-0000-0000-0000-000000000003}")
TimeDelay(60)
DDRServiceLocal = ""

When executing the TriggerSchedule method using the 2015A compiled version the compiled exe will crash and throw a windows error.

From Application log in event viewer
Faulting application name: SCCMRefreshV4.1normal.exe, version: 1.0.0.0, time stamp: 0x54be88a9
Faulting module name: OLEAUT32.dll, version: 6.1.7601.17676, time stamp: 0x4e58702a
Exception code: 0xc0000005
Fault offset: 0x00003e8d
Faulting process id: 0x1548
Faulting application start time: 0x01d0a2df387a26d0
Faulting application path: C:\software\SCCMRefresh\SCCMRefreshV4.1normal.exe
Faulting module path: C:\WINDOWS\system32\OLEAUT32.dll
Report Id: 76e2ab40-0ed2-11e5-a010-000ffecd4ec2

The exact same code run using the 2013C compiled version does not cause the AppCrash error. However WWWBatch.ini errors are listed:

[COM/CLR Exception]
SWbemObjectEx=Not found
[COM & CLR Sub-system]
Function=InvokeMember
ErrorCode=9 (0x80020009)
ErrorDesc=Exception occurred.

Now this behavior is only in a extreme situation where this process is initiated immediately after the PC finishes its task sequence.  After this process the SCCM client is not yet fully functional and takes ~10-15 min to complete its initialization.  When the client is not "ready" the TriggerSchedule is not available hence the error.  However in our case this function is in a loop with ErrorMode(@OFF) this loop simply waits and retries again for a set number of attempts.  So for a while now if this was to occur in the field the "errors" were transparent and the process simply retried and finished when it was able to successfully update.  Now exe crashes and needs to be re-launched, which is a minor annoyance.  As expected if you wait the expected period of time for the client to become "ready" the code works as expected. 

Was there significant change in the error handling from 2013C and 2015A?  Is this behavior intended or is this perhaps a bug?   

Thanks

[td]

There are no known changes to the WIL interpreter between 2013A and 2015A that could cause the crash nor have there been any changes to WinBatch error handling.  Since the crash is occurring in the Windows system dll ' OLEAUT32.dll',  your error could be the result of any number of changes other than your WinBatch version.

[Chris.Kubiak]

Was playing with it some more in this case I specified a schedule ID that never exists (saves rebuilding machines for a small window of testing).

Message("","2015")
DDRServiceLocal = GetObject("winmgmts:\\.\root\ccm:SMS_Client")
;LogText = "Triggering DDR"
;GoSub Write2Log
DDRServiceLocal.TriggerSchedule("{XXXXXX00-0000-0000-0000-000000000003}")
;TimeDelay(60)
DDRServiceLocal = ""

Aside from changing the message to 2013 the same code is compiled with 2015a and 2013c.  Running each compiled exe on the same client device back to back the 2013c gracefully handles the error 2015a crashes.   

[td]

If you understand the nature of program faults, you will know that your 'playing' does not mean that the problem is in the latest version of WinBatch.  When a exe changes the exe layout in memory changes so an innocent external dll stack or heap overwrite in one version may not be innocent in the other.  This fact does not mean that WinBatch is to blame. It only means that WinBatch was unlucky.  This seem the more likely since nothing is known to have changed in WinBatch that would affect WinBatch COM exceptions handling or COM Automation in general.

Your best approach would be to change your script to not rely on system COM exceptions to detect states.

   

[Chris.Kubiak]

Thanks, I appreciate the feedback.

[td]

As luck would have it we were able to duplicate your problem and find a solutions.  As previously mentioned, a WMI anomaly is the source of the issue.  Thanks to the offset into Window's COM Automation DLL 'OLEAUT32.dll' you provide and a bit of assembly language deciphering, the entry point into OLEAUT32.dll used by WMI was determined.  This entry point and a bit of code analysis lead to a simple change in the WIL interpreter's COM method invoke module that works around the WMI issue.

As always, we appreciate users taking the time to report problems with sufficient relevant detail to allow us to find a solution.