Start Me Up

There are some news on this topic. ------- The list of affected operating systems is now available in the help file: affected_operating_systems.png ------- I created the first prototype of an updater. It is capable of installing a new version of win32.sys and deinstalling it again: updater.png It comes in 24 languages, however, the end user will only see the language of the installed operating system. ------- First tests with the version 5.00.2196.0001V1 have shown, that the proposed solution is flawed. I documented my findings in the help file in the topic "version history" in the subtopic "version 1". ------- I have extracted 3 versions of win32k.sys from Windows Server 2008: Version 6.0.6002.18005 should contain a non fixed version of the function CreateXlateObject Version 6.0.6003.20665 should contain Microsoft's first attempt to fix the function CreateXlateObject Version 6.0.6003.20785 should contain Microsoft's second and final attempt to fix the function CreateXlateObject ------- My new suggestion would be to do a side-by-side comparison to figure out how Microsoft fixed this issue. There is a new version of code.htm online with some space to document the analysis. However, the cells are still empty. ------- That's all I got so far.

Thanks for the feedback. I read that this happens when the file is stored on a network drive or opened with an UNC path but it is supposed to work from a local disc. Anyway, it's just a few htm files and 1 css file compressed into a single chm file. It doesn't even contain java script or anything fancy. Todo: New Damage X (新DamageX) pointed out, that this issue could be related to ZDI-19-982. If this is true, then someone has found a way to exploit this issue to compromise security. Also, it would mean that there might be an official bug fix for newer versions of Windows out there which can be analysed to improve this update. I will check this soon. Edit: ZDI-19-982 leads to KB4525239

@tomasz86 Thank you. That's a veritable goldmine. Keep it online, please.

Well, I did. I am glad that it works for you anyway. Btw: If I remember correctly, I run into the problem on a system with a H2O BIOS from Insyde. The system works more or less ok with Windows 2000's original acpi.sys and ACPI-PC selected.

Backporting a newer version of ACPI.sys to Windows 2000 lead to an unstable system. The issue could not be resolved. No one involed knew what the many changes between the ACPI.sys from Windows 2000 compared to the new one was. So folks just tried to somehow force Windows 2000 to boot with the new ACPI.sys. Eventually Windows 2000 booted with ACPI 2.0 support. At this moment everyone just dropped everything and moved on with something else. That's why it was a waste of time. My suggestion would be to start with ACPI.sys from Windows 2000 and do small and clear changes step by step. Yes, I can help with the binary patching. I do a lot of low level programming. But I am not going to do everything alone.

Hello Windows 2000/XP fans, while I was working on a graphics driver, I noticed random crashes (blue screens) which were hard to reproduce. They don't happen often, but when using a display mode with 16 colors (for example 640x480x16 colors) they seem to happen more often than with other color depths. Eventually I was able to narrow down the problem and came to the conclusion, that the root cause is a buffer overrun in the function "CreateXlateObject" in the file "win32k.sys". This buffer overrun sometimes caused a random crash. In the most cases it happened within win32k.sys. I observed, that this issue is not fixed even in the newest version of win32k.sys from a Windows 2000 update from April 2016. An old version of win32k.sys from Windows XP has the same problem. I don't know which Windows XP update contains the newest version of win32k.sys for Windows XP, so I could not validate whether this issue was ever fixed - and if so: how. So I thought about what to do and came up with the idea, to write a Windows update of my own to fix this bug. So far I gathered necessary information and wrote a help file which contains most of what I know about the nature of this issue and how it can be fixed: OTSKB.chm There is some more auxilliary information available, which I do not plan to distribute among end users: code.htm Eventually, I fixed the win32k.sys from Windows 2000 manually with a hex editor to test the proposed solution: 5.00.2196.0001.zip The update, which would do this automatically and then install the new file automatically, is not written, yet. I would appreciate some feedback before I continue writing the update. Please let me know what you think. Maybe I just got it all wrong, don't know.

I tried to make my own driver unloadable first, because this should be easier than unloading vga.sys. When the user tries to remove the graphics circuit from the device manager, then my driver receives the following IRPs: DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_DEVICE_RELATIONS RemovalRelations DispatchPnP does: create a list with 1 entry (the DeviceObject it received) call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_REMOVE_DEVICE DispatchPnP does: IRP.IoStatus.Status = STATUS_SUCCESS call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_REMOVE_DEVICE DispatchPnP does: call DispatchPnP of videoprt.sys DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_DEVICE_RELATIONS RemovalRelations DispatchPnP does: create a list with 1 entry (the DeviceObject it received) call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_QUERY_REMOVE_DEVICE DispatchPnP does: IRP.IoStatus.Status = STATUS_SUCCESS call IofCompleteRequest DispatchPnP returns: STATUS_SUCCESS DispatchPnP gets called with: IRP_MJ_PNP IRP_MN_CANCEL_REMOVE_DEVICE DispatchPnP does: call DispatchPnP of videoprt.sys DispatchPnP returns: STATUS_INVALID_DEVICE_STATE Afterwards the display is removed from the device manager but the graphics circuit is still there. Also, the device manager asks for a restart to complete the removal. So I think for the display the process is: QUERY_DEVICE_RELATIONS -> QUERY_REMOVE_DEVICE -> REMOVE_DEVICE And for the graphics circuit the process is: QUERY_DEVICE_RELATIONS -> QUERY_REMOVE_DEVICE -> CANCEL_REMOVE_DEVICE For some unknown reason Windows decides not to continue with the graphics circuit removal process.

.

I do not have an external graphics card to test your theory. The integrated graphics circuits I have can't be removed from the system, because they are a subcircuit of the chipset or the processor. If the vga.sys driver is still blocking the system from going into sleep because it's still running in the background, is it still possible somehow to remove the blockade? Edit: I think what I need to do, is basicly to find a save and clean way to unload vga.sys and make sure it gets loaded again if my driver gets unloaded. Well, thank you @jumper. I think you gave me the crucial information I was missing.

Hello developers, in Windows 2000 we have the situation, that if there is a non-plug-and-play-capable driver active, then the shutdown options "standby" and "hibernation" are not available. For example the driver vga.sys of Windows 2000 prevents the system from going into standby mode. When vga.sys is replaced with a plug-and-play-capable driver by installing one and then restarting, then the power options are available. My graphics driver is capable of performing mode switching and turning off the display after a certain time of inactivity directly after the installation. But the additional power options are only available after the user has restarted the computer. videoprt.sys and my driver do not receive any IRP_MJ_POWER queries until the system has been restarted. When I try to enter the standby mode manually by calling ntdll.dll/NtSetSystemPowerState before the reboot I get a STATUS_CANCELLED and a STATUS_SUCCESS after the reboot. I am out of ideas about what the operating system is waiting for and why it needs the restart. Does anyone have an idea what the problem could be? Many thanks.