Deaktivierung der WOW64 Redirection ungünstig

[Dalai]

Hallo mal wieder (bei der Häufigkeit meiner Vorschläge könnte man auf die Idee kommen, ich wäre ein - bad pun alert - "Vorschlagshammer" )

Aufgrund der Thematik Fehler #0 beim Aufruf Update.cmd bin ich auf eine weitere ungünstige Implementation im UpdateInstaller aufmerksam geworden, die die Deaktivierung der WOW64 Redirection betrifft. Der derzeitige Aufruf führt zu keinem Fehler und funktioniert auch. Aber _WinAPI_GetLastError() nach dem DllCall() liefert Fehler 998 zurück:

Code: Select all

ERROR_NOACCESS
    998 (0x3E6)
    Invalid access to memory location.

Die Deklaration sagt, die Funktion Wow64DisableWow64FsRedirection() erwartet eigentlich einen Pointer (PVOID), der zur Speicherung von Informationen dient, die später von Wow64RevertWow64FsRedirection verwendet werden.

Lange Rede, kurzer Sinn: Ich hab mal in meinem AutoIt-Code gekramt, um zu schauen, wie ich das gelöst habe, und bin fündig geworden:

Code: Select all

local $Redirect, $pRedirect
$Redirect = DllStructCreate("uint")
if @error then Exit
$pRedirect = DllStructGetPtr($Redirect, 1)
DllCall("kernel32.dll", "bool", "Wow64DisableWow64FsRedirection", "ptr", $pRedirect)
; Do something
DllCall("kernel32.dll", "bool", "Wow64RevertWow64FsRedirection", "uint", DllStructGetData($Redirect, 1))
;--- release the memory for the variable
$Redirect = 0

Ist etwas mehr Code, aber bei dem liefert _WinAPI_GetLastError() immer 0 zurück, und natürlich hat er auch die gewünschte Wirkung.

Grüße
Dalai

[WSUSUpdateAdmin]

Dankeschön, Dalai,

"Vorschlagshammer"

Ich bin noch nicht dazu gekommen, gucke mir Wow64DisableWow64FsRedirection aber noch mal an - Dein Code ist sicherlich richtiger.
Ich hatte mir damals irgendein Beispiel gegriffen, aber in https://www.autoitscript.com/forum/topi ... direction/ klingt das ja auch schon an...

Viele Grüße und ein schönes Wochenende,
Torsten

[WSUSUpdateAdmin]

Moin Dalai,

die Änderungen hab' ich jetzt drin.

Viele Grüße und ein schönes Wochenende,
Torsten

[Gerby]

Hi!

Bei mir erscheint beim Start des Update-Prozesses aus dem UpdateInstaller (r931) ein Popup mit folgendem Inhalt:

Fehler #0 (API-Fehlercode: 18) beim Aufruf von Wow64DisableWow64FsRedirection.

Danach (beim Bestätigen mit OK) beendet sich der UpdateInstaller und nichts weiter passiert.

Ich weiß nicht, ob es konkret mit dieser Implementierung zusammenhängt, und leider habe ich auch aktuell keine Zeit zum Recherchieren, aber die Fehlermeldung deutet darauf hin.

Meine Umgebung für das Update: Windows 7 x64 (ist auf zwei unterschiedlichen Rechner so aufgetreten).

Gruß
Gerby

[Dalai]

Bis heute kam ich nicht dazu, mir die Änderungen anzuschauen. Es hängt definitiv mit der Implementierung zusammen.

Code: Select all

DllCall("kernel32.dll", "bool", "Wow64DisableWow64FsRedirection", "ptr*", DllStructGetPtr($pRedirect))

kann funktionieren. Weiß nicht, ob es besser ist, vorher das Struct zu erzeugen und dann einen Pointer darauf zu holen (wie in meinem Vorschlag).

In meinen Tests bekam ich zwar nie Fehlercode 18 (ERROR_NO_MORE_FILES) sondern Code 6 (ERROR_INVALID_HANDLE), aber das hängt vielleicht damit zusammen, dass ich UpdateInstaller.au3 in einem jungfräulichen WSUS Offline testete. Wichtig scheint mir daher zu sein, vor dem Aufruf von Wow64DisableWow64FsRedirection ein _WinAPI_SetLastError(0) einzufügen, um den Fehlercode zurückzusetzen und einen definierten Zustand zu erhalten.

Unabhängig davon ist hier wieder derselbe Fehler drin, wie ich ihn schon einmal bemängelte:

Code: Select all

If (@error <> 0) OR (_WinAPI_GetLastError() <> 0) Then
          If $gergui Then
            MsgBox(0x2010, "Fehler", "Fehler #" & @error & " (API-Fehlercode: " & _WinAPI_GetLastError() & ")" _
                                   & " beim Aufruf von Wow64DisableWow64FsRedirection.")
          Else
            MsgBox(0x2010, "Error", "Error #" & @error & " (API error code: " & _WinAPI_GetLastError() & ")" _
                                  & " when calling Wow64DisableWow64FsRedirection.")
          EndIf

Da ist ein Funktionsaufruf (_WinAPI_GetLastError) drin, der @error zurücksetzt, so dass die Meldung immer als ersten Wert 0 anzeigen wird, sofern nur _WinAPI_GetLastError ungleich 0 ist.

Grüße
Dalai

[Gerby]

Mit r932 tritt der von mir beschriebene Fehler nicht mehr auf.

Zum Code selber kann ich keine Aussage machen. Da steck ich nicht drin.

[WSUSUpdateAdmin]

Moin!

[...]Weiß nicht, ob es besser ist, vorher das Struct zu erzeugen und dann einen Pointer darauf zu holen (wie in meinem Vorschlag).

Auf jeden Fall!
Das hatte ich schlicht vergessen und mit r932 behoben.

[...]Wichtig scheint mir daher zu sein, vor dem Aufruf von Wow64DisableWow64FsRedirection ein _WinAPI_SetLastError(0) einzufügen, um den Fehlercode zurückzusetzen und einen definierten Zustand zu erhalten.

Ja, unglaublich aber wahr: Man ist offenbar vor einem Funktionsaufruf, dessen "LastError" man auswerten will, selbst dafür verantwortlich, diesen auf 0 zurückzusetzen, weil manche Funktionen ihn nur im Fehlerfall, nicht aber im Erfolgsfall setzen.
Vgl. dazu GetLastError function: "Most functions that set the thread's last-error code set it when they fail. However, some functions also set the last-error code when they succeed. If the function is not documented to set the last-error code, the value returned by this function is simply the most recent last-error code to have been set; some functions set the last-error code to 0 on success and others do not.".

Das muss ich komplett verdrängt haben, weil es einfach irre ist, aber sei's drum: _WinAPI_SetLastError(0) ist eingefügt.

Unabhängig davon ist hier wieder derselbe Fehler drin, wie ich ihn schon einmal bemängelte: [...] Da ist ein Funktionsaufruf (_WinAPI_GetLastError) drin, der @error zurücksetzt, so dass die Meldung immer als ersten Wert 0 anzeigen wird, sofern nur _WinAPI_GetLastError ungleich 0 ist.

Das trifft für _WinAPI_GetLastError() laut AutoIt-Doku nicht zu: "Remarks: @error and @extended are preserved on return."

Ich glaube daher, http://trac.wsusoffline.net/changeset/934 ist jetzt okay...

Viele Grüße
Torsten

[Dalai]

Das trifft für _WinAPI_GetLastError() laut AutoIt-Doku nicht zu: "Remarks: @error and @extended are preserved on return."

Oh, OK, dieser Hinweis findet sich erst in der aktuellen 3.3.14.5, nicht in der vorherigen 3.3.14.2. Sagen wir so: In diesem Fall ist das wohl so (ein Blick in den Code bestätigt die Doku). Andererseits schützt das Abspeichern von @error in einer zusätzlichen Variable in jedem Fall vor ähnlichen Fehlern in der Zukunft, wenn noch weitere/andere Funktionen gerufen werden sollten. Da aber weitere Änderungen an dieser Codestelle unwahrscheinlich sind (sag niemals nie ), würde ich es trotzdem so lassen.

Ich glaube daher, http://trac.wsusoffline.net/changeset/934 ist jetzt okay...

Sieht gut aus, obwohl ich mir nicht sicher bin, ob ptr* beim Aufruf von Wow64DisableWow64FsRedirection korrekt ist, wenn vorher schon ein ptr per DllStructCreate angefordert wird. Ist das dann ein Pointer auf einen Pointer auf einen Pointer? Dafür bin ich zu wenig Programmierer, um die korrekten Datentypen zwischen C++ und AutoIt umwandeln zu können.

Grüße
Dalai

[WSUSUpdateAdmin]

Moin!

ptr* (AutoIt) oder void** (C) ist ein Pointer auf einen Pointer, also eine Adresse, an der die aufgerufene Funktion einen Pointer (auf eine Struktur) ablegen kann (call by reference).
Bin alter C-Programmierer...

VG Torsten

[Dalai]

Soweit war mir das schon klar. Aber vorher wird ja im DllStructCreate schon ein ptr erzeugt, der nachfolgend als ptr* benutzt wird. Gesamt also ein Pointer auf einen Pointer auf einen Pointer, oder fügt DllStructGetPtr gar einen weiteren Pointer hinzu? Oder verstehe ich was falsch?

Mein Beispiel erzeugt einen uint, der nachfolgend nur als ptr verwendet wird. Gesamt also ein Pointer auf einen uint - was in Anbetracht der Deklaration der API-Funktion nicht korrekt ist.

Wäre es also folgendermaßen "richtiger"?

Code: Select all

local $pRedirect
$pRedirect = DllStructCreate("ptr")
if @error then Exit
_WinAPI_SetLastError(0)
DllCall("kernel32.dll", "bool", "Wow64DisableWow64FsRedirection", "ptr",  DllStructGetPtr($pRedirect))
; Do something
DllCall("kernel32.dll", "bool", "Wow64RevertWow64FsRedirection", "ptr", $pRedirect)
;--- release the memory for the variable
$pRedirect = 0

PS: Ich hasse Pointer. Ich bin eher in Delphi zuhause, wo man sich darum im Normalfall nicht kümmern muss.

Grüße
Dalai