jumper
jumper's Achievements
289
Reputation
-
Correct. "Exact Audio Copy is a so called audio grabber for audio CDs using standard CD and DVD-ROM drives." It only supports Redbook CD audio, but the drive can be any that reads audio CDs.
-
Aside from the heavy looping in ucrtbase and msvcp140, all looks good--v4 is doing its job. Did these runs exit silently?
-
Yes. The disc seems not to be compatible. Try it in a Blu-ray or DVD player to test the disc. ("Disc" is optical; "Disk" is magnetic)
-
I believe V4 is working and the Access Violation at 0xFFFFFFEA is just the next issue. Clear the Kstub log and run without DW. It won't launch, but we should see RaiseException (and hopefully more) in the new Kstub log and in the ApiLog window. Try with and without Kex debug mode. Meanwhile, I'm updating FineSSE to handle Continuable Exceptions and display a stack dump.
-
DW seems to be struggling. I used to recommend setting DW to the same mode as the app to be profiled. You can try that.
-
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)?
-
Yes: RaiseException(406d1388) again. Use =v4 and hope for additional debugging text from DebugBreak or OutputDebugString in the logs before the code -1 exit.
-
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. 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.
-
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.
-
From FF54_17.log: 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.
-
A couple of commits in the Firefox 54.0a1 (2017-02-15) build caused crashes and were reverted in the next day or two. So try -16 and -17. And check the kexstubs log files to see which apis were called.
-
Flash 9 not working on NT 4.0? (consolidated thread)
jumper replied to ironman14's topic in Windows 2000/2003/NT4
. -
Flash 9 not working on NT 4.0? (consolidated thread)
jumper replied to ironman14's topic in Windows 2000/2003/NT4
9.0.289 requires a CPU with SSE support. 9.0.47 and 10+ don't, but 10+ requires XP. FineSSE29 solves the SSE problem on Win9x, but hasn't been tested with NT4. -
exceeding max_path (path length > 260 characters)
jumper replied to Start Me Up's topic in Windows 2000/2003/NT4
For FAT and NTFS drives, API wrappers could walk the path string and shorten each long folder or file name as needed. Network shares to other file systems could be a problem. Temporary environment variables and drive mappings might also be possible. I've considered these possibilities for KernelEx should the need arise, but haven't done any tests. For years I have been successfully using a function I wrote to walk a path string and lengthen each short folder or file name. Doing the opposite should be easy. -
Ungoogled would be a fork, not a port. Please stay on-topic.