CORE-20279
PRELIMINARY REMARK: The described bug and code workaround only applies
for x86 32-bit builds.
----
While the Winlogon notification handlers[^1] actually use a `STDCALL`
calling convention, which can be trivially verified by debugging the
official Windows <= 2003 winlogon.exe and its notification extensions,
there exist 3rd-party Winlogon notification DLLs, like the `Ati2evxx.dll`
one from AMD/ATI XP video drivers, that use a `CDECL` calling convention,
or an invalid number (zero) of parameters.
I think the reason why this happens is as follows.
The official documentation[^1] indicates that the handlers have the
following prototype:
```c
void Event_Handler_Function_Name(
_In_ PWLX_NOTIFICATION_INFO pInfo
);
```
The documentation (and possibly the internal header Windows is using for
Winlogon) is sloppy, because it doesn't tell whether the convention is
`STDCALL` or `CDECL`. When compiling routines with such a signature, the
compiler will employ whatever default convention it is set to use.
Windows code is typically compiled with `STDCALL` convention as the default
(see e.g. how the Windows Development Kit is set up), thus, such a
function signature would default to `STDCALL`. Observation (with debugger)
shows that it is what Windows' winlogon.exe is indeed expecting.
However, 3rd-party code using a different development environment, could
set the compiler to use `CDECL` as the default calling convention. As a
result, the function signature from above would use `CDECL` instead.
The difference between the `STDCALL` and `CDECL` conventions is how the
function parameters are passed on the stack and how the stack is cleaned
at the end (`STDCALL`: the function unwinds the stack; `CDECL`: the caller
does it). A calling convention mismatch would therefore corrupt the stack,
and this is exactly what happens with the `Ati2evxx.dll` from the AMD/ATI
drivers, see CORE-20279.
The ReactOS Winlogon crashes from the `_RTC_Failure()` handler just after
the 3rd-party handler returns, since we compile our code with runtime checks
enabled. Windows' winlogon.exe doesn't apparently crash, because neither
in Release nor in Checked/Debug mode did they compile winlogon.exe with
RTC enabled. However, its stack would become more corrupt with time.
In order to alleviate this in ReactOS' winlogon.exe, I decided to use
a "generic" workaround, manually calling the handler with inline ASM
(which is OK since the problem and solution is x86-specific only).
It does something similar to what the RTC support does: it checks the
stack pointer after the call and restores it if needed.
An informative message is then emitted in the debugger telling which DLL
is buggy and needs to be fixed.
[^1]: https://learn.microsoft.com/en-us/windows/win32/secauthn/event-handler-function-prototype
- Move the existing function from automount.c
- Implement required function for the assign and remove commands.
Deleting a drive letter works, until the next reboot.
Assigning a new drive letter fails.
- Also improve the parameter checks of the remove command.
The assign command does not work, because the SetVolumeMountPointW function is not implemented yet.
- Implement creation and deletion of GPT partitions.
- Adjust the active, clean, detail, inactive, list, select, setid and uniqueid
commands as needed.
- Add a 2^32 sector count limit for MBR partition tables.
- FMIFS: QueryDeviceInformation(): Use more specific types and improve documentation.
Follow-up to commit 4838d7bd56.
- FORMAT: wmain():
* Zero the correct variable. Addendum to commit c5a9f22d4e.
* No need to zero the whole volumeName array. Follow-up to commit 358fecdcf0.
Commit 51ee32f5f8 moved the `WNetClearConnections()` in the main
Winlogon thread, where it now runs.
`WNetClearConnections()` calls a 3rd-party module (nfs41_np.dll)
that invokes `kernel32!OutputDebugStringA()`.
The SEH usage pattern in `OutputDebugStringA()`, when compiled with
GCC and PSEH, generates an erroneous chain of exception handlers, that,
when running in an execution environment like that of winlogon.exe,
triggers a crash. See CORE-20316 for more details and testing.
As a temporary measure, hackfix away the problem by surrounding the
`WNetClearConnections()` call in a `_SEH2_TRY/_SEH2_EXCEPT` block
(the net effect is to "add" the missing exception handler entry).
Hack for commit 51ee32f5f8
CORE-20307 CORE-20309 CORE-20316
- The single default button in the "Shutdown Computer" and "GINA failed
to load" dialogs will be automatically focused by the dialog manager,
so there is no need to invoke `SetFocus()` in their `WM_INITDIALOG`
handler -- which also erroneously returned `TRUE`, thus ignoring any
focus set by the caller :D
- Use `DeleteMenu()` instead of `RemoveMenu()` so that it'll free any
memory resources.
