Closed dominicraf closed 2 years ago
I have tried uninstalling NTVDMx64 with the debug version of ldntvdm and re-installing with the standard version (date 2022-02-07 02:44), and it doesn't help, sadly...
Hm, installing Access 97 on Windows 11 was a challenge on its own, but I finally got it running there. However, I'm note able to reproduce the issue with an empty Access database. Can you supply an Access database where I can reproduce the issues you are experiencing together with a detailled step-by-step instruction? The log unfortunately doesn't give enough information. That would be helpful for debugging.
No problem, here is a zipped example test-crash.zip - a simple new empty database, after opening it I go to the Reports tab and click 'New', then in the pop-up box I click 'OK' (leaving the 'Design View' option selected). Access97 crashes after a few seconds (the report never opens).
Windows 11 10.0.22000.493, problem still occurs with Windows Security/Defender real-time protection switched off.
Windows Event Viewer output (not very helpful, I suspect):
Faulting application name: MSACCESS.EXE, version: 8.0.0.5903, time stamp: 0x35ee15c2
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc000041d
Fault offset: 0x08e0002a
Faulting process ID: 0x1854
Faulting application start time: 0x01d81ff3c8b81bf5
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office\MSACCESS.EXE
Faulting module path: unknown
Report ID: 156401dc-d306-4281-a481-55e78d4c65e4
Faulting package full name:
Faulting package-relative application ID:
Hm, no isseus here... MS Access 97 with SR1 and SR2 patches installed.
Hmmm, do you have Windows 11 v10.0.22000.493? I recently installed KB5011093, KB5009469, KB5010386 - I wondered if it could be one of these, but I have now rolled them all back and I still have the same problem.
What you can do to diagnose the issue is downloading x64dbg, run the x32dbg.exe, load MSACCESS.EXE into it and run it with F9.. Then try to reproduce the error. When the excception occurs, you should end up in the debugger again. If it's just a RPC_E_ERROR_UNAVAILABLE or something like that, continue with F9. I suspect that it crashes at loading the WOW64 spooler in the NtCreateUserProcess hook of ldntvdm. For me, the hook works without issues:
But if you end up with a crash or an exception, you can check the crash location in the debugger. You may want to place a Breakpoint at CreateProcessInternalW and then step into the hooked NtCreateUserProcess with F7 and then gradually step through, unteil the error occurs:
OK thanks for the suggestion. I've done that and this is what I see at the crash point:
and then if continue I see this (I don't really understand any of this of course, but I note the mention here of 'return to ldntvdm.74486011 from ???':
I hope this is helpful!
... but, and here it gets weird, after this I carried on hitting F5 to get it to continue and then Access97 worked (i.e. the new report opened). And now, even outside the debugger, Access97 works fine. But it didn't work until I ran it in the debugger. I will reboot and see what happens...
I think this could be due to the fact the wow64 spooler got loaded and as long as it is loded, there is no further need to load it and therefore no further need for ldntvdm.exe to inject into it and therefore no more crashes. Unfortunately, on your images, I cannot see the code above the crash location and no full call stack (see tab call stack) and no memory map to see where we are here where it crashes (I guess some allocated inline hook memory chunk) You also need to download debug symbols for the libraries on the call stack (tab symbols, right click appropriate module, i.e. kernel32.dll and tell it to download symbols).
OK I confirm exactly same behaviour after reboot. Run Access97 outside the debugger, try to start a new report -> crash. Run Access97 inside the debugger, try to start a new report, skip over a couple of stops in the debugger -> new report opens. After this, Access97 runs fine even outside the debugger - until reboot.
I will try to get you more information from the debugger (of course I have to reboot)...
OK here it is on rerun with the CPU tab and the (top part of) the Memory Map tab and the Call Stack tab. Hope it helps!
You breaked at the wrong location.. As I initially said, skip over RPC_E_ERROR_UNAVAILABLE, it's a normal exception that should be handled by application (press F9 there, the Access violation is what we are looking for)
To download symbols, please go to Symbols tab, right click kernelbase.dll download symbols, right click ntdll.dll, download symbols, righ click kernel32.dll, download symbols, to have a more meaningful callstack. you only need to do that once, it will preserve symbols for further runs.
OK I have downloaded the symbols (possibly I downloaded the ones for ntdll.dll too late to be used here) and went to the next breakpoint, hopefully this is more meaningful:
This memory map screenshot might be more useful as it shows msaccess.exe and ldntvdm.dll:
Hmm, it crashes inside the WOW64 migration shelllcode.
I found something interesting here which isn't in my version of the shellcode:
mov ax, ds ; fixes an elusive bug on AMD CPUs, http://blog.rewolf.pl/blog/?p=1484
Do you by chance have an AMD CPU? That would also explain why it doesn't crash for me
Yes I have AMD Ryzen 5 5600G
Updated loader, can you check?
Yes that works - many thanks 👍 👍 👍 Off topic: When installing NTVDMx64 it says some exclusions are added to Windows Defender, could you add exclusions for ldntvdm.dll and ntvdm.exe both in C:\Windows\System32 and C:\Windows\SysWOW64 as well, as these triggered defensive action by Windows until I excluded them. I've also seen nasty warnings about C:\Windows\Temp\OLD*.tmp when uninstalling NTVDMx64.
The exlcusions the loader adds are in fact exclusions for ldntvdm.dll in System32 and syswow64 folder, see: https://github.com/leecher1337/ntvdmx64/blob/db63a0d65c576ce0a6375d9419259d7b637efc68/ntvdmpatch/release/install.bat#L146 No idea why you still have to manually add them again...
Agreed that is strange. (To correct what I wrote earlier: I have not seen Defender action against ntvdm.exe, only ldntvdm.dll, but including C:\Windows\SysWOW64\ldntvdm.dll as well as C:\Windows\System32\ldntvdm.dll).
This is a weird one. With NTVDMx64 installed, my Access 97 (32-bit) app is liable to crash when doing certain things (e.g. opening a report). Running with Dbgview on I see this appear when the crash is just happening (note: not running a 16-bit app inside NTVDMx64 at the time). Looks like LDNTVDM.DLL is being called (perhaps by the code in Access that displays a report?) and the version we are using doesn't support the necessary functions? I never had this problem before, though. I am using the debugging version of LDNTVDM.DLL, could this is the cause?
Uninstalling NTVDMx64 solves this problem (but then I can't run my DOS programs...):