Investigating a fork failure

[Jon TURNEY]

I'm not very happy with the assumption that this is SEP, so I did a bit 
more investigation into the problem in [1]

Installing "Lavasoft Ad-Aware Web Companion" into a W7 x86_64 VM, I'm 
able to reproduce that problem.

Running 'XWin -multiwindow' under WinDbg, with "Debug child processes 
also" enabled, a 2nd chance exception occurs in bash, with the following 
call stack:

>  # Child-SP          RetAddr           Call Site
> 00 00000000`0022e2e0 00000000`7755f37a ntdll!KiUserCallbackDispatcher+0x1b
> 01 00000000`0022e338 00000000`7755f3af USER32!NtUserRegisterWindowMessage+0xa
> 02 00000000`0022e340 000007fe`fe2f80f2 USER32!RegisterWindowMessageW+0x2b
> 03 00000000`0022e390 000007fe`fe2f8014 OLEAUT32!_RegisterClipFormat+0xc2
> 04 00000000`0022e470 000007fe`fe2f33c1 OLEAUT32!_typesDllMain+0x4c
> 05 00000000`0022e4a0 000007fe`fe2f3356 OLEAUT32!DllMain+0x21
> 06 00000000`0022e4d0 00000000`7768b108 OLEAUT32!CRT_INIT+0x2af
> 07 00000000`0022e630 00000000`7767787a ntdll!LdrpRunInitializeRoutines+0x1fe
> 08 00000000`0022e800 00000000`77677b5e ntdll!LdrpLoadDll+0x231
> 09 00000000`0022ea10 000007fe`fd439059 ntdll!LdrLoadDll+0x9a
> 0a 00000000`0022ea80 000007fe`ff917d66 KERNELBASE!LoadLibraryExW+0x22e
> 0b 00000000`0022eaf0 000007fe`ff915d22 ws2_32!DPROVIDER::Initialize+0x156
> 0c 00000000`0022f090 000007fe`ff933a90 ws2_32!DCATALOG::LoadProvider+0x7e
> 0d 00000000`0022f0c0 000007fe`ff920b9b ws2_32!DCATALOG::GetCountedCatalogItemFromCatalogEntryId+0x70
> 0e 00000000`0022f100 00000001`800ab085 ws2_32!_chkstk+0x362a
> 0f 00000000`0022f1a0 00000001`8006d8b7 cygwin1!feinitialise+0x33f95
> 10 00000000`0022f1f0 00000001`800469d0 cygwin1!dlfork+0x3ac7
> 11 00000000`0022f250 00000001`8004897c cygwin1!setprogname+0x3ed0
> 12 00000000`0022f2c0 00000001`800c62e9 cygwin1!cygwin_dll_init+0x16ac
> 13 00000000`0022f320 00000000`7768b108 cygwin1!dll_entry+0x149

I interpret this to mean the situation is something like the following:

LavasoftTcpService64.dll is being loaded as a LSP
LavasoftTcpService64.dll depends on OLEAUT32.dll
OLEAUT32's DllMain calls RegisterWindowMessage
This ends up calling KiUserCallbackDispatcher for a kernel to user-mode 
callback.
This accesses a pointer to a callback table at PEB:0x58, which is 
unfortunately null.
Sadness follows.

I wonder if anyone has any insight into this or suggestions for further 
investigation?

[1] https://cygwin.com/ml/cygwin/2015-08/msg00312.html