Archive for the ‘64bit’ Category

Binärtyp einer EXE-Datei unter Windows ermitteln, ob 32- oder 64-Bit–man spricht auch von Bitness

27 Juli 2016

Möchte man unter Windows bei einer ausführbaren Datei wissen, ob diese eine 32-Bit oder 64-Bit Version ist, dann kennt die Win32-API die Funktion GetBinaryType. Mittels Powershell kann man diese Funktion wie folgt nutzen:

$MethodDefinition = @‘

// https://msdn.microsoft.com/en-us/library/windows/desktop/aa364819(v=vs.85).aspx
[DllImport("kernel32.dll")]
public static extern bool GetBinaryType(string lpApplicationName, out uint lpBinaryType);

‚@

$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name ‚Kernel32‘ -Namespace ‚Win32‘ -PassThru

# Funktioniert aber nur, wenn man sich in einem 64-Bit Prozess befindet, also: [System.IntPtr]::Size -eq 8
$type=0
$Kernel32::GetBinaryType("c:\windows\system32\cmd.exe", [ref] $type)  # unter 64-Bit sollte es 6 sein
$type
$Kernel32::GetBinaryType("c:\windows\syswow64\cmd.exe", [ref] $type)  # unter 64-Bit sollte es 0 sein
$type

# mögliche Werte für $type:
# SCS_32BIT_BINARY = 0, // A 32-bit Windows-based application
# SCS_64BIT_BINARY = 6, // A 64-bit Windows-based application.
# SCS_DOS_BINARY = 1,   // An MS-DOS – based application
# SCS_OS216_BINARY = 5, // A 16-bit OS/2-based application
# SCS_PIF_BINARY = 3,   // A PIF file that executes an MS-DOS – based application
# SCS_POSIX_BINARY = 4, // A POSIX – based application
# SCS_WOW_BINARY = 2    // A 16-bit Windows-based application

Dabei ist zu beachten, wenn man den Test macht, dass IntPtr 8 liefern sollte, sonst befindet man sich in einem simulierten WOW64-32Bit-Prozess und bekommt verwunderliche Ergebnisse zurück.

Advertisements

Auswirkungen von 32-Bit Programmen unter 64-Bit Betriebssystemen

14 September 2015

Ein Kunde hat einen Brother PTouch Labeldrucker. Nach dem Umzug auf Windows 8.1 lief die zugehörige Software nicht mehr. Um dem Problem auf die Spur zu kommen war prinzipiell eine Aktualisierung der Client PTouch Software notwendig. Beim Testen zeigten sich aber die typischen Probleme bei Verwendung von 32-Bit Programmen unter 64-Bit Windows-Betriebssystemen. Deshalb hier mal exemplarisch was man machen kann und vor allem, wie sich die Probleme äußern.

Generell bietet es sich an, wenn man Problemen auf den Grund gehen möchte, eine Eingabeaufforderung zu öffnen. Jetzt muss man aber wissen, dass man unter einem 64-Bit Betriebssystem unter Windows normalerweise auch die 64-Bit CMD.EXE erhält. In der Regel klappt damit alles problemlos aber bei bestimmten Dingen provoziert man dadurch auf einmal ein anderes Verhalten.

So hatten wir ein Testskript in VBScript geschrieben, welches einfach nachvollziehbar ein Objekt erzeugen sollte. Der betreffende Eintrag lautete:

Set objDoc=CreateObject("bpac.Document")

als Fehlermeldung gab es aber immer

C:\Temp\TestDruckDirekt.VBS(10, 1) Laufzeitfehler in Microsoft VBScript:
ActiveX-Komponenten kann kein Objekt erstellen: ‚bpac.Document‘

Blöd sowas, aber wer verwendet noch VBScript? Also Powershell aufgerufen und da gibt es was ähnliches:

$c=new-object -ComObject "bpac.Document"
new-object : Die COM-Klassenfactory für die Komponente mit CLSID
{B940C105-7F01-46FE-BF41-E040B9BDA83D} konnte aufgrund des folgenden Fehlers
nicht abgerufen werden: 80040154 Klasse nicht registriert (Ausnahme von
HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
In Zeile:1 Zeichen:4
+ $c=new-object -ComObject "bpac.Document"
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [New-Object], COMExcept
   ion
    + FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Comman
   ds.NewObjectCommand

Zwar ausführlicher aber im Prinzip die gleiche Meldung wie bei VBScript. Solche Geschichten sind immer irgendwie doof.

Da man aber in Powershell mehr Möglichkeiten hat, bietet sich z. B. dieses an: https://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/. Damit kann man ganz einfach sehen, ob man unter einem 32-Bit oder 64-Bit Prozess läuft.

[System.IntPtr]::Size
8

Aha, also 8, d.h. die aktuelle Eingabeaufforderung ist unter 64-Bit unterwegs. Also nochmal denselben Test gemacht, nachdem mit

START C:\Windows\SysWOW64\CMD.EXE

eine neue Eingabeaufforderung explizit als 32-Bit Prozess gestartet wurde. Dort brachte dann die Überprüfung mittels Powershell die 4 für einen 32-Bit Prozess als Ergebnis.

Wenn man nun unter dieser Shell das Testscript.VBS aufruft, läuft alles.

Hat man Batchdateien in diesem Zusammenhang laufen, dann kann man die Umgebungsvariablen PROCESSOR_ARCHITECTURE und PROCESSOR_ARCHITEW6432 abfragen. Speziell wenn die Umgebungsvariable PROCESSOR_ARCHITEW6432 vorhanden ist, weiß man, dass man unter einem 64-Bit-System unter einem 32-Bit Prozess unterwegs ist. Hier ist die Sache mit PROCESSOR_ARCHITEW6432 näher beschrieben: http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx

VirtualBox Probleme mit 64-Bit Gast und das Ding mit dem Client-Hyper-V

31 Oktober 2014

Als bekennender Hyper-Vler bin ich über ein Problem gestoßen. Es ging darum eine virtuelle Maschine zu haben, über die man problemlos auf den USB Port losgehen kann. Leider ist da Hyper-V auch in aktuellen Ausprägungen nicht so der Bringer. Also nimmt man einen anderen VM-Host, wie in diesem Fall VirtualBox von Oracle: https://www.virtualbox.org/.

Nach der Installation war es aber nicht möglich ein 64-Bit Gastsystem aufzusetzen. Nach dem üblichen Überprüfen der BIOS-Einstellungen, damit auch die nötigen Virtualisierungseinstellungen aktiv waren, funktionierte es immer noch nicht. Dann diesen Artikel gelesen: https://forums.virtualbox.org/viewtopic.php?f=1&t=62339. Aha Hyper-V! Aber der läuft doch gar nicht!?!?

PS C:\Windows\system32> Get-Service -DisplayName *hyper*

Status   Name               DisplayName
——   —-               ———–
Stopped  vmicguestinterface Hyper-V-Gastdienstschnittstelle
Stopped  vmicheartbeat      Hyper-V-Taktdienst
Stopped  vmickvpexchange    Hyper-V-Datenaustauschdienst
Stopped  vmicrdv            Hyper-V-Remotedesktopvirtualisierun…
Stopped  vmicshutdown       Hyper-V-Dienst zum Herunterfahren d…
Stopped  vmictimesync       Hyper-V-Dienst für Zeitsynchronisie…
Stopped  vmicvss            Hyper-V-Volumeschattenkopie-Anforderer
Stopped  vmms               Hyper-V-Verwaltung für virtuelle Co…

PS C:\Windows\system32>

Dann Hirn eingeschaltet und an BCDEdit erinnert, dass es dort zig Einstellmöglichkeiten zum Hyper-V gibt. http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

OK, dann mal nachgeschaut:

bcdedit /enum

Dabei wurde folgendes ausgegeben:

Windows-Startladeprogramm
————————-
Bezeichner              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 8.1
locale                  de-DE
inherit                 {bootloadersettings}
recoverysequence        {4b6f8314-5573-15e4-b299-de2a5ae3ac48}
integrityservices       Enable
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4b6f8312-5575-15e4-b299-de2a5ae3ac48}
nx                      OptIn
bootmenupolicy          Standard
hypervisorlaunchtype    Auto

Ja alles klar. HypervisorLaunchtype steht auf Auto und sollte entweder nicht da sein oder auf Off stehen.

Hier wird beschrieben wie man einen weiteren Eintrag im Bootmenü generieren kann: http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

Dadurch kann man beim Rechnerstart auswählen, ob der Hyper-V Hypervisor aktiviert werden sein soll oder nicht.

Entscheidend dabei sind:

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
Dadurch wird ein weiterer Eintrag ins Bootmenü geschrieben. Die GUID
ff-23-113-824e-5c5144ea sieht aber bei jedem anders aus. Es stellt nur
eine eindeutige Kennung dar.

Da aktuelle Rechner recht schnell beim Booten sind, hilft ein weiterer BCDEdit Befehl in Zukunft den richtigen Eintrag beim Start automatisch auszuwählen:

bcdedit.exe /bootsequence {ff-23-113-824e-5c5144ea}


shutdown.exe /r /t 0 /f

Damit wird der Rechner mit dem neuen Bootmenüeintrag gestartet.

Man könnte dies nun über Powershell automatisieren aber der BCD WMI Provider hat so scheinbar seine Tücken: https://social.technet.microsoft.com/Forums/scriptcenter/en-US/18094085-781f-4649-8ff8-331388097911/how-to-get-boot-configuration-data-bcd-information-out-of-wmi-with-powershell?forum=ITCG

Netsh und 32-Bit 64-Bit Abhängigkeit

8 Februar 2014

In der vor Powershell 4.0 Zeit aber teilweise aktuell immer noch, benötigt man unter Windows hin und wieder Netsh. Mittels Netsh kann alles mögliche in Sachen Netzwerk konfiguriert werden, von Netzwerkadressen über Firewall bis hin zum Tracing von Ereignissen.

Hier einige Beispiele, wo auf diesem Blog bisher Netsh zum Einsatz kam: https://newyear2006.wordpress.com/?s=netsh

Wichtig zu wissen in diesem Zusammenhang ist, dass Netsh abhängig von der Umgebung reagiert, was einem oft nicht bewusst ist, denn es gibt einmal Netsh für 32-Bit und einmal für 64-Bit Umgebungen.

Im Fall von WinHttp Proxy Einstellungen ist dies wichtig zu wissen, denn sonst wirken sich gemachte Proxy Einstellungen nicht aus! http://blogs.msdn.com/b/jpsanders/archive/2010/09/16/winhttp-proxy-settings-in-64-bit-x64-environments.aspx

Erst seit Windows 8 bzw. Server 2012 wird bei den Proxy-Einstellungen dafür gesorgt, dass Netsh sich auf beide Bereiche auswirkt. (Siehe Kommentare).

SilverDAT über Netzwerkclient installieren

16 September 2013

Aus aktuellem Anlass, wegen Installation auf Windows 8.1 64-Bit, hier die Beschreibung wie man den SILVERDAT Netzwerkclient installiert. Dieser Artikel ersetzt diesen alten: https://newyear2006.wordpress.com/2006/01/26/silverdat-netzwerkclient-installieren/

Wichtig, damit es funktioniert, muss ein Netzlaufwerk verbunden sein und zwar als Admin, am besten man startet den Vorgang in der Eingabeaufforderung mit Adminrechten.

Mittels

NET USE N: \\SERVER\SDII

stellt man eine Verbindung her, wechselt dann mittels

N:
CD \SDII\D\D\EXE.W95

ins Installationsverzeichnis und startet dort

instclt.exe

Es erscheint zwar eine Fehlermeldung wegen fehlender URLMON.DLL aber diese Meldung kann vernachlässigt werden. Danach installiert man das Programm. Am Ende startet man noch

autostrt.exe

für die Druckereinrichtung. Das wars.

Weitere Infos zu SilverDAT II: https://www.dat.de/products/products_systems/SilverDATII.page

Fehler 0x0000007e beim Versuch einen HP-Netzwerk-Drucker auf einem Windows 8 Rechner zu installieren

19 März 2013

Tja, Sachen gibt es in dieser Welt. Man stelle sich vor, man möchte einem Windows 8 Rechner mit 64-Bit einen Drucker zuordnen, der von einem 32-Bit Rechner freigegeben wurde. Weiter stelle man sich vor, es handelt sich um einen beliebigen Drucker von Hewlett-Packard.

Was kommt heraus, wenn die größten Kröten in der Branche gemeinsame Sache machen? Jawoll, diese Fehlermeldung:

Druckerverbindung kann nicht hergestellt werden. Fehler bei Vorgang: 0x0000007e

Der eine ist zu blöd eine sinnvolle Fehlermeldung auszugeben und der andere ist zu blöd seine Treiber ordentlich anzupassen. Es soll ja angeblich nur homogene IT-Umgebungen geben!

Ein Microsoft Fuzzi schreibt darüber auch noch einen netten Blog-Eintrag – wie toll, dass man mal eben ein paar HP-Entwickler auf seinem Campus hat! Blöd nur, wenn man wie unsereins, der den Scheiß ausbaden darf, diese Möglichkeiten nicht hat.

http://blogs.technet.com/b/dmelanchthon/archive/2011/04/26/operation-failed-with-error-0x0000007e.aspx

Man muss also am Printerserver einfach diesen Registry-Key löschen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\
Printers\<PRINTERNAME>\CopyFiles\BIDI

Interessant auch mal wieder, dass so was nicht in der Knowledge Base bei Microsoft steht. Ach Entschuldigung, ist ja der Fehler von HP. Eigentlich möchte ich mich gleich bei beiden entschuldigen, überhaupt deren Produkte einzusetzen. Ich glaub da läuft gerade ein Fass über…

Prüfen, ob eine Powershell Sitzung in einer 32Bit oder 64Bit Prozess-Umgebung läuft

20 Juni 2012

Wichtig um Probleme schneller beheben zu können ist immer die Kenntnis, in welcher Umgebung, also ob 32Bit- oder 64Bit-Umgebung, man sich befindet.

In Powershell gibt es verschiedene Möglichkeiten dies herauszufinden. Leider zeigt die normale Versionsinfo dies nicht direkt an. Siehe auch: https://newyear2006.wordpress.com/2009/12/07/powershell-2-0-versionsabfrage/. Auch eine Abfrage von Get-Host bringt die gewünschte Info nicht zutage.

Aber es gibt ja noch andere Möglichkeiten. Die einfachste ist

[Environment]::Is64BitProcess

Alternativ gibt es noch den Weg über die Plattformpointergrößen-Abfrage:

[IntPtr]::Size

Wird hier 4 zurückgegeben ist man in einem 32Bit Prozess, bei 8 befindet man sich in einem 64Bit Prozess. http://stackoverflow.com/questions/8588960/determine-if-current-powershell-process-is-32-bit-or-64-bit

Öffnet man unter Windows 7 mit 64Bit oder Windows 8 mit 64Bit, bzw. Server 2008 R2 oder Windows Server 2012 mittels CMD.EXE eine Eingabeaufforderung und startet von dort Powershell, befindet man sich immer in einer 64Bit Umgebung. Erst wenn man explizit mittels Aufruf von

C:\Windows\SysWOW64\cmd.exe

explizit die 32Bit-CMD.EXE startet, gelangt man in die 32Bit-Powershell Umgebung.

16Bit Fibu lässt sich nach Umzug von NT4-Server auf SBS2011 nicht mehr starten

29 April 2011

Eigentlich keine große Sache, es sollte eine in sich geschlossene Fibu welche im Netz auf einem NT4-Server gespeichert war, umgezogen werden auf einen Small Business Server 2011. Bei der Fibu handelt es sich um die GDI-Fibu für Windows in einer älteren 16Bit Version. Eigentlich genügt es das Verzeichnis auf einen anderen Rechner zu schieben und es läuft.

Aus dieser Kenntnis heraus, war also mit keinen Problemen mit dem Programm bei der Serverumstellung zu rechnen. Aber weit gefehlt. Als das Verzeichnis N:\WINFIBUNEU beim neuen Server übernommen wurde, wurde das passende Netzlaufwerk N: bei der Verknüpfung eingerichtet und los konnte es gehen. Denkste.

Beim Aufruf der Verknüpfung gabs ne Fehlermeldung:

Fehler in 16Bit-Bit-Windows-Programm

Datei "N:\WinFibuNeu\fibu.exe” (oder Komponente) nicht gefunden. Überprüfen Sie, ob der Pfad- oder Dateiname korrekt sind und ob alle erforderlichen Bibliotheksdateien zur Verfügung stehen.

Hä was soll das? Das Verzeichnis kurz auf die lokale Platte gespielt und läuft. Also eine Abhängigkeit kann es nicht sein. Also zu wenig Rechte auf dem Netzlaufwerk? Nein, auch der Admin hat Probleme.

Zum Glück gibt es den Process Monitor von Sysinternals. Mit diesem wurde die ganze Sache mal aufgezeichnet, was im Hintergrund so alles passiert.

Siehe da, bei einem CreateFile-Aufruf sollte das Verzeichnis N:\WinFibuN geöffnet werden aber als Result steht “NAME NOT FOUND”. Ist ja logisch, denn das Verzeichnis heißt ja auch N:\WinFibuNeu!

Aber was ist der Grund? Na klar, die guten alten 16Bit Programme können halt nix mit den langen Dateinamen anfangen. Also braucht es den Kurznamen in 8.3 Notation. Ja aber beim NT4-Server gabs doch auch keine Probleme! Richtig, der war aber auch 32Bit und der SBS2011 ist 64Bit und da ist 8.3 Notation ausgeschaltet!

Wer es nicht glaubt ein kleines

fsutil behavior query C:

auf dem Serverlaufwerk liefert den Beweis.

Und die Moral von der Geschicht? 16- und 64Bit vertragen sich nicht!

Okay wenn man das Problem kennt, dann kann man auch hergehen und den Verzeichnisnamen auf 8 Zeichen kürzen, dann klappt wieder alles. Also aus N:\WinFibuNeu wurde N:\WinFibuN. Das wars.

Gespiegelte Boot Partitionen Einrichten mit GPT Datenträgern unter Windows Server 2008

16 Februar 2011

Eine ziemlich detaillierte Schritt für Schritt Anleitung wie man einen dynamischen, gespiegelten GPT-Bootdatenträger unter Windows Server 2008 einrichtet, beschreibt dieser Knowledge Base Artikel: http://support.microsoft.com/kb/951985/en-us

Oder das gleiche für 2003: http://support.microsoft.com/kb/814070/en-us

GPT-Boot-Datenträger mit Diskpart einrichten

16 Februar 2011

MBR und 16bit ade, jetzt schlägt die Stunde von 64bit und UEFI. Es gibt noch nicht viele Informationen über GPT-Datenträger zum momentanen Zeitpunkt. Man muss sich noch alle möglichen Infos aus allen Ecken zusammentragen. GPT steht übrigens für GUID Partition Table. MSR steht für Microsoft Reserved Partition und ESP für EFI System Partition.

Die wichtigsten Begriffe im Zusammenhang mit GPT, MSR und ESP werden hier geklärt: http://www.microsoft.com/whdc/device/storage/gpt_faq.mspx

Schema eines GPT-Datenträgers: http://www.microsoft.com/whdc/device/storage/gpt-on-x64.mspx

Nochmal eine schematische Darstellung von GPT-Datenträgern in Verbindung mit der Aufteilung der Partitionen: http://blogs.technet.com/b/askcore/archive/2010/10/08/gpt-in-windows.aspx

Aber eines ist sicher: GPT bringt viele Vorteile bei der Festplattenverwaltung und dass moderne Festplatten optimal angesprochen werden können (Thema Alignment). Dazu noch UEFI mit 64bit Code wo vorhandenen Speicher, der in der Regel im Überfluss da ist, nun auch optimal verwenden kann. Endlich lässt sich der Flaschenhals mit dem Ruhezustandsmodus entschärfen.

Trotz aller Vorteile ergeben sich noch ewig viele Fragen.

Als erste wäre dies: Wie erstellt man einen GPT-Datenträger unter Windows 7? Ganz einfach, mittels

CONVERT GPT

Allerdings darf davor keine Partition auf der Platte vorhanden sein, also löscht man diese mittels CLEAN.

GPT-Datenträger sind aber ganz anders aufgebaut und benötigen neben der eigentlichen Datenpartition gleichmal zwei zusätzliche Verwaltungspartitionen EFI-Systempartition und MSR.

Schön dargestellt und wie man diese einrichtet, stellt dieser Artikel dar: http://technet.microsoft.com/de-de/library/dd744301(v=WS.10).aspx

Tipp: Achso, GPT mag Vorteile bringen und gibt es schon relativ lange, allerdings werden die Kinderkrankheiten in Verbindung mit UEFI Bootvorgängen erst gerade ausgemerzt. Man sollte also nach Möglichkeit sein 64bit Windows 7 mit der GPT-Bootpartition erst einrichten, wenn man ein Windows 7 mit integriertem Service Pack 1 Installationsdatenträger hat.

Beispiel: http://support.microsoft.com/kb/975535/ 
und http://support.microsoft.com/kb/979374

Weitere Probleme: VHD-Boot ist nicht möglich: http://www.delltechcenter.com/page/uEFI+Boot+to+VHD oder mögliche Probleme mit Hyper-V: http://www.mcseboard.de/virtualisierung-82/windows-server-backup-efi-maschine-hyper-v-nutzen-167416.html

Wird alles noch richtig spaßig!