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 yesterday at 09:12 AM 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 21 hours ago by woi
Serpent 52

[jumper]

8 hours ago, woi said:

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

The log looks good until IP suddenly jumps to high system space. A crash dialog stack dump or Dr.Watson stack unwind would be helpful here to see where execution came from. What happened to the RaiseException error? That was the reason for trying in DW and Finesse.

 

8 hours ago, woi said:

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.

They don't all need to be redirected. Avoid API-MS-WIN dlls as much as possible, redirecting them to Kernel32.dll itself or other system dlls. See my API-MS-Win.reg file for details.

Try using KernelEx XP-Debug mode for possibly more messages in AppLog. If already doing so, try changing IsDebuggerPresent to Kexbases.0 (0:False, 1:True) in Core.ini to possibly avoid the RaiseException errors when not profiling in DW.

 

[woi]

I tried using debug mode with IsDebuggerPresent enabled, seems like it crashes on NSS3 instead of XUL (probably further than it should be?).

Here I provided both DrWatson and ApiLog logs for Mypal68 (updated for WATSON05_NODBG.WLG, XP SP3 mode without debug) : Mypal.zip

Dependency Walker (XP debug mode):

Edited 6 hours ago by woi

[jumper]

Yes: RaiseException(406d1388) again. Use =v4 and hope for additional debugging text from DebugBreak or OutputDebugString in the logs before the code -1 exit.

 

[woi]

Tested RaiseException=v4, and 0xFFFFFFEA exception seems to appear again in both XP SP3 and XP SP3 (Debug mode): WATSON07.WLG

Edited 4 hours ago by woi

[jumper]

Dr.Watson seems to completely disagree with Dependency Walker:

Trap 03 0000 - Breakpoint trap
eax=61dd11ec ebx=bff66d80 ecx=00000028 edx=9344ecbc esi=00d08f60 edi=00000000
eip=620b1c4c esp=007cf9bc ebp=007cf9c8         -- -- -- nv up EI pl ZR na PE nc
cs=016f ss=0177 ds=0177 es=0177 fs=234f gs=0000
XUL.DLL:.text+0x90c4c:
>016f:620b1c4c cc                  int     3

Exception Code: 80000003 (hardcoded breakpoint)
Exception Address: 620b1c4d (XUL.DLL:.text+0x90c4d)

Depends.dll is not listed as a loaded module, but neither is Concrt140.dll. Does Dependency Walker show a handled Breakpoint Trap further up in its log (before the Concrt140 process attach)?

 

[woi]

There isn't (I did not save the logs on the screenshot) but it should be same as this one: Mypal_DW.txt

And yes I'm using Windows XP Debug mode + RaiseException set to v4.