After applying the Gen 8.6 PTFs to 31 Jan 2022 and building the 2 .exe files & their associated .dll files the application execution on some machines fails with errors such as:
Faulting application name: LOAD1000.EXE, version: 1.0.0.1, time stamp: 0x5da05d67
Faulting module name: wrgn.dll, version: 8.6.0.4176, time stamp: 0x5c1ab9af
Exception code: 0xc0000409
Fault offset: 0x0028d926
Faulting process id: 0x3dc
Faulting application start time: 0x01d82de2164a2f97
Faulting application path: T:\G86\TST-X\LOAD1000.EXE
Faulting module path: T:\G86\TST-X\wrgn.dll
Report Id: f2306438-6236-41b8-a310-fe3b89273a3f
Faulting package full name:
Faulting package-relative application ID:
Faulting application name: LOAD1000.EXE, version: 1.0.0.18, time stamp: 0x621e96b6
Faulting module name: ntdll.dll, version: 10.0.18362.2037, time stamp: 0x011891c6
Exception code: 0xc000041d
Fault offset: 0x0003a1b8
Faulting process id: 0xea8
Faulting application start time: 0x01d82de18b9d5eb8
Faulting application path: T:\G86C\DEV-Y\LOAD1000.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: bfc8df1d-4586-463b-b929-483de5d251da
Faulting package full name:
Faulting package-relative application ID:
Faulting application name: LOAD1000.EXE, version: 1.0.0.18, time stamp: 0x621e96b6
Faulting module name: mfc140.dll, version: 14.28.29914.0, time stamp: 0x605e53b7
Exception code: 0xc000041d
Fault offset: 0x002ad1c9
Faulting process id: 0x18b0
Faulting application start time: 0x01d82ddb25180bf7
Faulting application path: T:\G86C\DEV-Y\LOAD1000.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\mfc140.dll
Report Id: b60bb944-41b6-42e0-b2e4-28dce7f13a22
Faulting package full name:
Faulting package-relative application ID:
A number of machines still work as expected.
Notably the failing machines launch a second instance of LOAD1000.exe, replacing the first.
Gen Run Time, GUI
A non-Gen external OLE code oleudf.dll is being called via Gen INVOKE action diagram statements on its OLE window object.
After applying the Gen 8.6 PTFs, using the latest Visual Studio 2017 build of oleudf.dll encounters the problem but using the older Visual Studio 2008 build of oleudf.dll does not.
The user has not yet been able to recreate the failure in a sample application which calls the same external dll and is continuing to refine that sample application to try to recreate the problem while also performing further debugging of the real application which encounters the failure in Visual Studio 2017.
Gen Engineering has advised there should not be a problem with using the old VS 2008 oleudf.dll build with fully PTF'd Gen 8.6 environment as a workaround while user continues to investigate the problem. If that older version stops working Engineering would not investigate with that version and the user would need to upgrade/rebuild it for debugging to be done with that new version, which is effectively what they are trying to do now.
At this time the user decided to defer applying the 8.6 PTFs and continue to use the Visual Studio 2017 build of oleudf.dll rather than using the workaround of the older Visual Studio 2008 build of oleudf.dll with the 8.6 PTFs applied.