Vorhandene! bcdedit.exe kann NiCHT vom Script ausgeführt werden weil es diese exe nicht findet

Candyland

Hallo geehrte Community,

beim Versuch eine Automatisierte Treiber entfernung zu schreiben, wobei automatisch in den Abgesicherten Modus gebooted werden soll & zurück stolperte ich über ein Problem das ich so vorher noch nie sah.

Wenn ich versuche per Script bcdedit.exe (startkonfigurations manager) zu öffnen zeigt mir die CMD an 'Der befehl "bcdedit" ist entweder falsch[..]'. So versuchte ich also ersteinmal zu schauen ob ich denn Manuell per CMD an bcdedit rankomme und siehe da wenn ich per WIN+R ~> CMD ~> bcdedit eingebe zeigt er mir diverse Informationen an die von der exe stammen.

So schaute ich mir also an wo denn überhaupt die exe ihren ort hat und das ist im \System32\ Ordner. Um jetzt einmal direkt das Script die exe anzupeilen, ohne erfolg.

Bei google und co suchte ich mit präfixen wie "bcdedit program inkompatiblität known bugs incompatibility" usw. Doch stieß nicht wirklich auf einen Nenner der ein ähnliches Problem von sich gab.

So dachte ich mir es wäre wohl angemessen das Script eine .bat kreieren zu lassen die dann ausgeführt wird da ich per .bat ohne probleme an bcdedit rankam. Doch sobald ich diese .bat per Script starte leitet er wiedermals ein "nicht gefunden" an mich weiter.

Ich fühle das mir die Möglichkeiten momentan ausgegangen sind. Ich denke das eventuell jemand von euch fixen Programmierern das schoneinmal gesehen hat mit einer anderen exe.

Also zusammengefasst:

C:\Windows\System32\bcdedit.exe ~ existiert

WIN+R ~> cmd.exe ~> bcdedit ~ gibt mir den output der exe zurück

C:\Windows\System32\bcdedit.exe mit einem Script von autoit ausgeführt kann nicht gefunden werden

Außerdem ist mir nichts in den Sicherheitseinstellungen aufgefallen, so kann also jeder nutzer mit Admin rechten darauf zugreifen.

Hier ein Bild zur verdeutlichung (Das mit dem Bild geht irgendwie nicht ganz)

[Blockierte Grafik: https://img2.picload.org/image/dodlwdpw/wtf.png]

Viele Grüße euer Candyland

**alpines**

Ich schätze mal es ist das selbe Problem wie letztens in einem anderen Thread (ich find den nicht mehr).

Der eigentliche Dateiname lautet vermutlich ganz anders und bcdedit.exe ist nur ein Softlink dorthin.

**bernd670**

Hallo,

nutzt du evtl. eine 64bit-Version von Windows? Dann probiers mal mit #AutoIt3Wrapper_UseX64=y.

**AspirinJunkie**

alpines: Meinst du den hier: >>Klickmich<<

**alpines**

AspirinJunkie ne, es war ein anderer. BugFix hatte dort den richtigen Pfad zu der Datei gepostet.

**bernd670**

Der gesuchte Thread ist wohl Windows-Fax und -Scan aufrufen. Das ist aber bei bcdedit.exe nicht der Fall. Wäre aber auch egal, denn AutoIt ist auch in der Lage diese, per Hardlink verknüpfte Dateien, zu starten. Da die Datei aber nur im system32-Verzeichnis liegt, hat Candyland wohl nur vergessen auf 64Bit umzuschalten.

Candyland

Probiere ich gleich morgen früh alles aus. Toll das ihr mir so Schnell geantwortet habt. Ich wundere mich nur warum es nicht reicht die exe direkt anzusteuern per Pfad. Und außerdem ist die CMD weiterhin 64bit was heißt das egal ob durchs Script oder durchs doppelklick die .bat gestartet wurde. Also "@Comspec & ' /C ' & $bcdedit" sollte trotzdem funktionieren weil schlussendlich die cmd bcdedit startet. So jedenfalls mein gedanke

misterspeed

Da das Problem mit der Windows FS Redirection zu tun hat (System32 / SysWOW64) wäre es durchaus denkbar, dass die "Redirections" oder evtl. das bereits umgeleitete "Workingdir" an Unterprozesse vererbt werden, genauso wie das mit "Admin-Rechten" geschieht. Ist aber nur eine Vermutung. Alternativ zu einem 64bit Autoit Script könntest du im Übrigen auch den virtuellen "Sysnative" Ordner nutzen um von einer 32bit Anwendung auf 64bit Systemdateien zuzugreifen.

http://www.samlogic.net/articles/sysna…bit-windows.htm

**AspirinJunkie**

Zitat von Candyland

Und außerdem ist die CMD weiterhin 64bit was heißt das egal ob durchs Script oder durchs doppelklick die .bat gestartet wurde. Also "@Comspec & ' /C ' & $bcdedit" sollte trotzdem funktionieren weil schlussendlich die cmd bcdedit startet.

Nein.

@Comspec ist lediglich ein String der auf die cmd.exe im Ordner System32 verweist.
Aufrufe dorthin von einem 32 Bit-Programm auf einem 64 Bit System werden implizit nach SysWOW64 umgeleitet.
Daher ruft @Comspec in dem Fall die 32 Bit-Version der cmd.exe im SysWOW64-Ordner auf.

Zitat von misterspeed

Alternativ zu einem 64bit Autoit Script könntest du im Übrigen auch den virtuellen "Sysnative" Ordner nutzen um von einer 32bit Anwendung auf 64bit Systemdateien zuzugreifen.

Danke - kannte ich noch nicht.
Alternativ kann man es auch pauschal z. B. über die _WinAPI_Wow64EnableWow64FsRedirection() abschalten.

**bernd670**

Hallo,

sysnative kann aber leider nur von 32bit Programmen benutzt werden. Wenn etwas braucht was sowohl von 64bit als auch unter 32bit funktioniert, kann man das so machen wie es z.B. von OPSI genutzt wird. Man legt sich im Windows-Verzeichnis eine Kopie / Link zur 64bit cmd an mklink %windir%\cmd64.exe %windir%\system32\cmd.exe. Danach kann man von 32bit und 64bit Programmen mit Run(@WindowsDir & "\cmd64.exe /c ....." auf die 64bit Umgebung zugreifen.

misterspeed

Hab ich zwar nie getestet / benutzt, aber wozu so umständlich / unschön? Ich würde grundsätzlich niemals mit Windows Systemdateien / Verzeichnissen rumspielen wenn das nicht zwingend notwendig ist. Dafür benötigt man im Übrigen normalerweise auch erhöhte Rechte.

Selbst wenn "sysnative" in 64bit Scripten nicht verfügbar ist kann man doch trotzdem bei Bedarf (32bit Script) damit arbeiten. Wenn man ein 64bit Script hat nutzt man eben die ganz normalen "SYSTEM32" Pfade und braucht garnichts weiter tun. Wenn du aus 64bit Scripten auf die 32bit CMD console zugreifen willst ersetzt du System32 eben mit "SysWOW64"

Könnte dann so ausschaun:

AutoIt

;#AutoIt3Wrapper_UseX64=n
#AutoIt3Wrapper_UseX64=y

If @AutoItX64 <> 1 And @OSArch = "X64" Then
    $sCMD32console = @ComSpec
    $sCMD64console = StringReplace(@ComSpec,"system32","Sysnative")
    $debug = "64bit OS + 32bit Script:" & @CRLF
Else
    If @OSArch = "X86" Then
        $sCMD32console = @ComSpec
        $sCMD64console = -1 ; nicht verfügbar, da 32bit OS
        $debug = "32bit OS + 32bit Script:" & @CRLF
    Else
        $sCMD32console = StringReplace(@ComSpec,"system32","SysWOW64")
        $sCMD64console = @ComSpec
        $debug = "64bit OS + 64bit Script:" & @CRLF
    EndIf
EndIf

ConsoleWrite($debug & "32bit Console: " & $sCMD32console & @CRLF & "64bit Console: " & $sCMD64console & @CRLF)

Exit

Alles anzeigen

Candyland

Zitat von AspirinJunkie

Meinst du den hier: >>Klickmich<<

Dort ist auch von \Sysnative\ die rede

Zitat von bernd670

Candyland wohl nur vergessen auf 64Bit umzuschalten.

Ich möchte tatsächlich das Script kompatibel für sowohl 32Bit und 64Bit haben, da es nicht dafür bestimmt ist nur auf diesem Computer/der Virtuellen maschine zu laufen. Genauer gesagt automatisiere ich DDU, für den fixen fall das ich mehere Computer Bediene und ich deshalb nicht jeden Schritt Manuell ausführen muss, auch wenn der Aufwand gering ist.

Zitat von misterspeed

Alternativ zu einem 64bit Autoit Script könntest du im Übrigen auch den virtuellen "Sysnative" Ordner nutzen um von einer 32bit Anwendung auf 64bit Systemdateien zuzugreifen.

Diese Lösung werde ich Nutzen!

Zitat von bernd670

Man legt sich im Windows-Verzeichnis eine Kopie / Link zur 64bit cmd an

Das was du hier anbietest finde ich wirklich gut, kommt in meine Computerinstallations Routine absofort mit rein

Vielen Dank für die Hilfe und Mühe an euch alle!

Grüße!