Thread::SuspendThread and ResumeThread will probably crash .NET apps that use them
pub31415 opened this issue · comments
Great work on the backport and the "movie" about it!
I wrote a whole blogpost about what ndphlpr.vxd does lel
Since the project intercepts the call to DeviceIoControl and forces OutBuffer to 0x40 while ndphlpr.vxd is not really loaded, mscorwks.dll will try to use non-functional APIs for Thread::SuspendThread and ResumeThread
https://pub31415.bearblog.dev/what-ndphlprvxd-does/
I cant test it though, since I dont have .NET on me.
Hey thanks for the writeup! Now something will finally show up when you google it ;)
I have indeed been made aware of NDPHLPR's true purpose since posting the video (there are also references in leaked Windows code that make its usage clear that I won't link here), and yes you're probably right the hack I've implemented will presumably cause thread issues in the long-term.
So I guess the question remains - why doesn't NDPHLPR.VXD load on Windows 95 and what can be done to resolve that?
why doesn't NDPHLPR.VXD load on Windows 95
in the control routine, on initialisation, there's a version check, against 4.10 (ie, windows 98)
If NDPHLPR.VXD can be patched to remove the 98 check or even just make NDPHLPR.VXD stub for the Windows/... folder so it will load correctly. I wonder what modern windows does with this check, anyway?
If NDPHLPR.VXD can be patched to remove the 98 check or even just make NDPHLPR.VXD stub for the Windows/... folder so it will load correctly. I wonder what modern windows does with this check, anyway?
My guess is Windows for weird architectures that don't support multi-tasking/multi-threading.
I would bet that Windows XP Embedded and NT 4.0 Embedded would still have the check, not sure if the modern Embedded/IoT version would still have it.
Possibly Windows for ARM.
leaked Windows code that make its usage clear that I won't link here
Don't keep us in the dark. What was the purpose of the driver?