Firefox 24 - 52 for ME and 98

[woi]

OK here it is: KSTUB825.log

[jumper]

From FF54_17.log:

Quote

1|ffff9fc3| [FIREFOX.EXE]00406012:<KERNEL32.DLL>GetModuleHandleW(bfa5087b)
1|ffff9fc3| [FIREFOX.EXE]00406012:<KERNEL32.DLL>GetModuleHandleW|400000
1|ffff9fc3| [UCRTBASE.DLL]00669c2c:<KERNEL32.DLL>GetModuleHandleW(bfa5087b)
1|ffff9fc3| [UCRTBASE.DLL]00669c2c:<KERNEL32.DLL>GetModuleHandleW|400000
1|ffff9fc3| [UCRTBASE.DLL]00665edf:<KERNEL32.DLL>LoadLibraryExW(bfa4c4a2)
1|ffff9fc3| [UCRTBASE.DLL]00665edf:<KERNEL32.DLL>LoadLibraryExW|0
1|ffff9fc3| [UCRTBASE.DLL]006696d3:<KERNEL32.DLL>GetModuleHandleExW(bfa4bba7)
1|ffff9fc3| [UCRTBASE.DLL]006696d3:<KERNEL32.DLL>GetModuleHandleExW|0
1|ffff9fc3| [UCRTBASE.DLL]006696a5:<KERNEL32.DLL>ExitProcess(bfa4dfeb)

Shortly after XUL.dll successfully loads, Firefox.exe gets its own handle ([FIREFOX.EXE]00406012:<KERNEL32.DLL>GetModuleHandleW|400000) then makes a call into UCRTBASE.dll which tries to explicitly load another dll. That load fails ([UCRTBASE.DLL]00665edf:<KERNEL32.DLL>LoadLibraryExW|0) and so does an attempt to get a module handle (GetModuleHandleExW|0). UCRTBASE then quits by calling ExitProcess, probably after displaying the broker services error message. FF54_16.log is the same. I see no evidence of a crash--Firefox.exe appears to terminate normally.

If you Profile Firefox.exe in DependencyWalker, it should show the name of the dll UCRTBASE fails to load. While the broker services error is still displayed, looking in Procwin16 at the Firefox.exe code after 00406012 might reveal what UCRTBASE api before 00669c2c was called. Also the string passed to LoadLibraryW should be findable.

As for KSTUB825.log, it is full and no longer logging anything. Just delete it to start a new log.

 

[woi]

Dependency Walker logs, kinda strange that the broker services error did not appear when running the -17 version: FF54_DW.zip

1 hour ago, jumper said:

While the broker services error is still displayed, looking in Procwin16 at the Firefox.exe code after 00406012 might reveal what UCRTBASE api before 00669c2c was called. Also the string passed to LoadLibraryW should be findable.

Also is this correct (procwin):

 

Edited 7 hours ago by woi

[jumper]

The results are different: In 16 XUL does not load. In 17 it fails much later with thread 18 quitting after successfully loading WBEMSVC.dll. Were the symptoms the same? What versions of UCRTBASE.dll have you tried? Also try using KnownDLLs to redirect UCRTBASE to MSVCR140 or lower.

The code at 406012 seems to just be checking for tampering in its own header, but makes no calls to UCRTBASE.

'First chance exception 0x406D1388 (Thread was named) occurred in "c:\program files\ff54_17\XUL.DLL" at address 0x0173AF59 by thread 10 "JS Helper".' -- This shows how a debugger can handle a RaiseException and continue without crashing. Mypal68 shouldn't be making that call when not running in a debugger. Try running Mypal68 in DW or Finesse.

 

[woi]

I still can't launch Mypal68 on Dependency Walker (exception in 0xFFFFFFEA): MP68_DW.txt

4 hours ago, jumper said:

What versions of UCRTBASE.dll have you tried? Also try using KnownDLLs to redirect UCRTBASE to MSVCR140 or lower.

I'm using the one from Firefox 52 (10.0.14393.33), obviously the ones from Mypal68 does not work at all. I have not managed to redirect UCRTBASE to MSVCR140 (MSVCP140?) as the api-ms-win files already redirected there (it still ask for UCRTBASE.DLL), if I redirect those to MSVCP140 it complains about MSVCP140:Free.

UPDATE: I launched tried FineSSE and it's the showing same exception

Also forgot to mention but I'm using the latest version 74.1.4 (don't be fooled, it's still 68). I'll test the older 68.1x.x versions and see if there's any differences.

Update 2: Tested Mypal68 v68.13.1, same error 0xFFFFFFEA, also happens on unmodified Serpent 52 as well.

Edited 1 hour ago by woi
Serpent 52