Coding

Virtual Shadow Copy Services - Create Shadow Copy

Dirk Eisenberg — Tue, 22 Apr 2008 02:07:23 GMT

Einige Abende haben mich nun die icht mehr ganz so neuen Virtual Shadow Copy Services beschäftigt. Für alle die genauso wie ich eine Shadow Copy einer Partition anlegen wolle um mit ihrer Platte irgendetwas in einem stabilien Zustand zu bewerkstelligen sollte dieser Code hilfreich sein. Das Ziel des hier abgebildeten Codes soll es sein eine Virtual Shadow Copy einer Partition zu erzeugen und mit Hilfe von Win32-Apis auf diese zuzugreifen. Der Code beinhaltet natürlich viel zu wenig Error-Handling und achtet auch nicht auf die korrekte Freigabe von Resourcen. Nun aber los:

CoInitializeEx( NULL, 0 );
Zuerst muss COM initialisiert wert, dazu muss man wohl nichts mehr sagen.

IVssBackupComponents* pBackupComponents = NULL;
if ( FAILED( CreateVssBackupComponents( &pBackupComponents ) ) )
return 1;
Um überhaupt mit dem VSS-Api arbeiten zu können wird ein Pointer auf ads BackupComponents-Interface benötigt. Dieses Objekte stellt dann Methoden zur Verfügung um VSS zur Arbeit zu überreden. Wichtig bei allen folgenden Methoden-Aufrufen ist die Reihenfolge. Hier legt Microsoft genaue Abläufe fest die umbedingt eingehalten werden müssen. Wer sich nicht daran hält wird mit Error-Codes bestraft (ich habs probiert).

hr = pBackupComponents->InitializeForBackup( NULL );
Nachdem wir Zugriff auf das BackupComponents-Objekt erhalten haben, ist die erste Amtshandlung dem System zu sagen wir wollen ein Backup machen. Hierzu muss die Methode InitializeForBackup aufgerufen werden. Erst hierdurch können die nachfolgenden Methoden aufgerufen werden.

hr = pBackupComponents->SetContext( VSS_CTX_BACKUP );
Dem System ist im dritten Schritt zu sagen welche Art von Backup und damit welche Art von Snapshot erzeugt werden soll. Hier gibt es verschiedene Möglichkeit, grundsätzlich sind aber zwei zu Unterscheide. Eine Variante bezieht die sogenannten Writer mit ein und die andere eben nicht. Writer stellen Userland-Applikation dar die auf bestimmte Aktionen des VSS-Systems reagieren und vor einem Backup bestimmte Aktionen zu beenden. Datenbanken würden alle wichtigen Informationen noch auf die Platte schreiben damit die Datenbank auch in einem brauchbaren Zustand ist. Hat man Softare die keinen VSS-Support bietet, muss wohl der Weg über Stop-Service und Start-Service eben dieser gegangen werden. Erst danach ist es ratsam eine Shadow-Copy zu erzeugen. Wie man Writer schreibt werde ich einem anderen Eintrag versuchen darzustellen.

IVssAsync* pWriteMetaData = NULL;
hr = pBackupComponents->GatherWriterMetadata( &pWriteMetaData );
pWriteMetaData->Wait();
pWriteMetaData->Release();
Da wir Writer-Aktionen in unser Backup einbeziehen, müssen auch die Meta-Daten über diese abgefragt werden. Hierdurch erlangt das System genau Informationen welche Writer wie und wann benachrichtigt werden müssen. Diese Aktion kann durchaus etwas länger dauer. Aus diesem Grund wird hierfür eine Pointer für assynchrone Operationen zurückgegeben mit dessen Hilf das Ende abgewartet werden kann.

VSS_ID snapshotSetId;
hr = pBackupComponents->StartSnapshotSet( &snapshotSetId );
VSS sieht die Sicherung des geamten Storage-Systems zu einem Zeitpunkt vor, daher reden wir nicht von einem Snapshot eines spezifischen Volumes sondern eine SnapShot-Set der eine Liste von einzubeziehenden Volumes verwaltet. Dadurch ist es Möglich z.B. die Partition für mdf und ldf in einem Snapshot-Set zu fixieren und später einfach zu sichern.

VSS_ID SnapShotId;
hr = pBackupComponents->AddToSnapshotSet( L"F:\\", GUID_NULL, &SnapShotId );
Haben wir den Container, das SnapShot-Set angelegt, müssen jetzt noch die einzelnen Targets hinzugefügt werden. Die einfachste Methode ist es via Laufwerksbuchstaben eine ganze Partition hinzuzufügren. Dieser Vorgang kann mehrfach für andere Volumes wiederholt werden.

hr = pBackupComponents->SetBackupState( false, false, VSS_BT_FULL );
Da auch inkrementielle Backups vorgesehen sind, ist noch die Art und Weise des Backups zu definieren. In diesem Beispiel wollen wir ein Full-Backup aller Dateien machen. Es gibt auch die Möglichkeit Dateien einzuschränken.

IVssAsync* pPrepare = NULL;
hr = pBackupComponents->PrepareForBackup( &pPrepare );
pPrepare->Wait();
pPrepare->Release();
Jetzt nähern wir uns dem Punkt der Wahrheit, dem VSS-System wird mitgeteilt das sich alle Writer und Provider auf das Backup vorbereiten müssen. Kurz darauf folgt dann die eigentlich Erzeugung des Snapshots.

IVssAsync* pDoShadowCopy = NULL;
hr = pBackupComponents->DoSnapshotSet( &pDoShadowCopy );
pDoShadowCopy->Wait();
pDoShadowCopy->Release();
Mit der Methode DoSnapshotSet wird dann für jede Komponente des Sets ein SnapShot erzeugt. Hierbei sorgt das Betriebssystem für die Konsistenz der Daten.

VSS_SNAPSHOT_PROP props;
hr = pBackupComponents->GetSnapshotProperties( SnapShotId, &props );
Nun fehlt nur noch die Information für den Zugriff via Win32-Api. Hierfür stellt die abgerufene Struktur eine Device-Pfad zur Verfügung auf den vie CreateFile und anderen IO-Operation zugegriffen werden kann.

pBackupComponents->Release();
Nur noch das Interface release und fertig.

Hinweis: In diesem Beispiel wurde ein temporärer Snapshot angelegt, d.h. wenn dieser nicht mehr benötigt wird, verschwindet dieser. Auch ein Restart des VSS-Service lässt den Snapshot verschiedenen. Will man persistente Snapshots, müssen die Flags entsprechend umkonfiguriert werden.

Mit dem Tool dosdev lassen sich so erzeugte Snapshots auch mounten und einem Laufwerksbuchstaben zuordnen. Mehr Informationen hierzu gibt es auf folgenden Seiten:

Aldi Olteans Blog (1) (2)
Downlod von dosdev

Ich werde in den nächsten Artikeln versuchen Schritt für Schritt andere Funktionen auf C++-Ebene zu beschreiben. Hierbei werden Themen wie das Schreiben von VSS-Writern und VDS-Hardware-Providern adressiert.

Debian Repository für iSCSI Enterprise Target

Dirk Eisenberg — Mon, 03 Mar 2008 00:56:22 GMT

Jeder der eine standard etch Installation sein eigen nennt kann jetzt entwerder via Apt oder per Download ein Debian-Paket für das iSCSI Enterprise Target 0.4.15 installieren. Ich werde in Zukunft diese Paket immer wieder aktualisieren.

hier gehts zum Paket

Wer selbst mal Pakete erstellen und APT-Repositories aufsetzen möcht, dem helfen vielleicht die folgenden Informationen:

Setting up your own APT repository with upload support
Create Debian Linux packages

WOW64 - Es lebe der 32Bit Prozess - Teil 2

Dirk Eisenberg — Tue, 07 Mar 2006 02:06:00 GMT

Und wieder hat mich die Schreibwut gepackt und ich möchte Versuche ein weiteres Problem beim Umgang mit 64Bit Windows Features aus einem 32Bit-Prozess heraus beschreiben. Wer sich schonmal die Frage gestellt hat, wie kommte man an den Wert der Variable %ProgramFiles%, kommt schnell zum entsprechendne MSDN Artikel und den Shell-APIs. Das Mittel der Wahl ist SHGetFolderPath und die passende CSIDL.

Was macht man aber unter 64Bit Windows, immerhin wird je ein %ProgramFiles% für 64Bit-Prozesse und eines für 32Bit-Prozesse angeboten. Ruft man also SHGetFolderPath aus einem 64Bit-Prozess aus bekommt man oft C:\Program Files zurück. Aus einem 32Bit-Prozess C:\Program Files(x86).

Warum ist das so?

Zusätzlich zur FileSystem-Redirection gibt es unter 64Bit Windows eine Registry-Redirection und der Registry-Value hinter SHGetFolderPath ist wie folgt zweimal verfügbar:

64Bit Prozesse
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir
32Bit Prozesse unter der WOW64 Emulation
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ProgramFilesDir

Wie kommt man jetzt an den 64Bit-Wert?

Was kann man nun machen um aus einem 32Bit Prozess sowohl das x86-ProgramFiles-Dir und das x64-ProgramFiles-Dir abzufragen und dabei auf einem legalen Pfad zu bleiben. Gut das Microsoft ein Set von Environment-Variablen Dokumentiert hat die uns weiter helfen werden. Die Folgende Matrix finde sich in der MSDN hier:

Environment Variable	64-bit Value	32-bit Value
PROCESSOR_ARCHITECTURE	Native (AMD64 or IA64)	x86
PROCESSOR_ARCHITEW6432	N/A	%PROCESSOR_ARCHITECTURE%
ProgramFiles	%ProgramFiles%	%ProgramFiles(x86)%
ProgramW6432	N/A	%ProgramFiles%
CommonProgramFiles	%CommonProgramFiles%	%CommonProgramFiles(x86)%
CommonProgramW6432	N/A	%CommonProgramFiles%

Ist davon auszugehen das seinem eigenem Prozess die Environment Variablen vererbt werden, ist alles in Butter. Durch einfach Kombination von IsWow64Process und GetEnvironmentVariable lässt sich ein kleines Set von Funktionen bauen die immer das geforderte Directory korrekt zurückgeben egal wie der Prozess daher kommt.

[Update] Der managed P/Invoke Mediator

Dirk Eisenberg — Mon, 06 Mar 2006 02:21:00 GMT

Wenn sich nach dem letzten Artikel vielleicht jemand fragt warum funktioniert das, sollte einen kurzen Blick auf die verschiedenen Bestandteile von Platform Invoke werfen. Daraus wird deutlich warum in einem Assembly DllImport-Verweise auf nicht existierende Dll vorhanden sein können und wann das .NET-Framework wie auf die native DLL zugreift.

Check this out: http://msdn2.microsoft.com/en-us/library/h50dxzwx.aspx

There are three parts to a .NET Compact Framework platform invoke:

At design-time, the developer provides a description of the unmanaged function to call. This includes the module name (DLL file), entry point name, and calling convention.
At just-in-time (JIT) compile time, the common language runtime extracts this information from the metadata, locates the DLL containing the function, loads the DLL into memory and retrieves the address of the function. If the module or function is not found, the common language runtime throw a MissingMethodException.
At run time, the common language runtime marshals the parameters from managed format to unmanaged format before the unmanaged function is called. The common language runtime
determines how to marshal each parameter based upon the managed declaration of the method.

Weiterhin sie auf das HowTo - Get the Device Platform verwiesen. Dadurch lässt sich der Platform Runtime Check auf sichere Beine stellen.

Der managed P/Invoke Mediator

Dirk Eisenberg — Mon, 06 Mar 2006 01:06:00 GMT

Nach dem letzten Blog meines gleichgesinnten Kollegens hat mich das Thema P/Invoke nicht mehr los gelassen. Ich ging nur mit einer etwas anderen Einstellung in das Thema. Mein Programmche soll nicht die File Redirection von %systemroot%\system32 nutzen. Nein ich will keine Forwarder-Library in das System32-Directory kopieren. Zustimmung erhält aber trotzdem das Mediator.Prinzip. Dieser Mediator bestimmt welche native DLL geladen wird. Im Fall von 64Bit Windows wäre das die 64Bit-Dll, im Fall von 32Bit Windows die 32Bit-Dll und im Falle von Windows CE und dem Compact Framework eine andere.

Mein Ziel ist aber die gesamte Distribution meiner Software in %ProgramFiles%\MySoftware zu handeln und eine foo.dll für 32Bit Windows, eine foo64.dll für 64Bit Windows und eine fooCe.dll für Windows CE zu halten.

Versuch Nummer 1:

Bendenkt man das Attribute in .NET nur Klasse abgeleitet von System.Attribute sind, liegt die Idee nah das DllImportAttribute erneut abzuleiten und im Property-Handling für den DllName die Logik für die Namens-Nomenklatur zu Implementieren. Leider macht das kleine aber wichtige Schlüsselwort sealed einen Strich duch die Rechnung. Damit sorgt das .NET Framework das keine weitere Ableitung von dieser Klasse möglich ist. Der nächste Versuch war irgendeine Art Logik hinter den DllName zu hängen. Leider unterstützt auch hier das .NET Framework nur konstante Parameter-Werte in Attributen. Also auf zu neuen Ufern.

Versuch Nummer 2:

Verfolgt man das Mediator-Konzept weiter, will aber keine eigene Forwarder-Dll schreiben, ist vielleicht folgendes Konzept hilfreich. Für jede unterstützte Plattform wird eine DllImportHelper-Klasse implementiert. Diese kapselt lediglich das Marshaling und die DllImport-Anweisung. Um den Zugriff auf die richtige Helper-Klasse zu realisierien wird eine Schnittstelle zur Verfügung gestellt. DieseDllImport-Klasse orchestriert den Zugriff auf die korrekte Helper-Klasse. Je nach aktueller Plattform wird die entsprechende Methode aus der korrekter DllImport-Helper-Klasse aufgerufen.

Vorteile:

Das Mediator-Konzept wurde beibehalten und das Assembly kann einfach um weitere Plattformen erweitert werden. Baut man das Konzept aus, so ist eine Erweiterung für neue Platformen in reinem Managed-Code ohne Veränderung des aufrufenden Codes möglich.
Die Verwaltung einer extra Forwarder-Dll entfällt.
Die Applikation muss keine Libraries in %systemroot%\system32 ablegen.

Nachteil:

Die Bestimmung der aktuellen Platform kostet extra Zeit und verlangsamt den Sprung in den native Code nochmals.
Es muss für jede Platform eine extra Klasse im Assembly gehalten werden aber kein zweites Assembly.

Ein einfaches Beispiel ist hier hinterlegt. Dieses Beispiel soll nur illustrieren wie das prinzipielle Vorgehen ist und wurde nicht für den produktiven Einsatz vorgesehen.

64Bit Runtime Check:

Wie findet der geneigte Entwickler in C# heraus ob sich der Prozess gerade als 64Bit bzw. 32Bit-Prozess läuft. Leider ist festzustellen das Microsoft in seinem Environment-Objekt keine passable Lösung für das Problem vorrätig hat. Folgende Lösung stammt aus diesem Blog und hier findet man wie es nicht gemacht werden sollte. Unter C# ist ein int-Datentyp immer 32Bit lang, egal ob 64Bit-Prozess der 32Bit-Prozess aber der IntPtr ist je nach Prozess-Art 32Bit oder 64Bit lang.

bool bIs64Bit = (sizeof(IntPtr) == 8 )

WOW64 - Es lebe der 32Bit Prozess

Dirk Eisenberg — Sat, 04 Mar 2006 15:22:00 GMT

Nach eingen Diskussionen mit hier nicht näher genannten Kollegen um das Thema File und Registry-Redirection unter 64Bit Windows habe ich mir die Frage gestellt, kann ein 32Bit-Prozess das automatische Redirecten überwinden oder nicht? Ich will die Antwort nicht vorweg nehmen, also hier das gesteckte Ziel:

"Ein 32Bit-Prozess soll einen Datei im 64Bit-Directory %systemroot%\System32 anlegen."

Unter 64Bit Windows wird das System32-Directory in einem 32Bit-Prozess, der unter der WOW64 Emulation getstartet wird, umgeleitet bzw. überblendet. Ein 64Bit Prozess sieht die Dateien aus %systemroot%\System32 ein 32Bit-Prozess hingegen die Dateien aus %systemroot%\SysWOW64. Nach einiger Einarbeitung in die SDK-Dokumentation zu WOW64 haben sich folgende APIs als Goldgrube erwiesen:

Mit IsWow64Process kann geprüft werden ob der aufgerufene Prozess unter WOW64 läuft. Ist das nicht der fall muss es ein 64Bit-Prozess sein oder ein 32Bit auf einem 32Bit OS. GetNativeSystemInfo hilft hier weiter.
Wow64DisableWow64FsRedirection schaltet wie der Name schon sagt das WOW64 File-Redirecting für den aufrufenden Thread aus. Zum reverten (nicht wieder einschalten, weil es ja bereits abgeschaltet gewesen sein kann) wird Wow64RevertWow64FsRedirection angeboten.

Der Ablauf um in das System32 für 64Bit Prozesse aus einem 32Bit Prozess zu schreiben sieht dann wie folgt aus:

Prüfen ob Prozess in der WOW64 Emulation läuft
FsRedirection ausschalten
Jetzt kann direkt auf das System32 zugegriffen werden, ohne das der Prozess in SysWOW64 umgeleitet wird.
FsRedirection reverten

Folgendes Beispiel demonstriert das beschriebene Verfahren:

int _tmain(int argc, _TCHAR* argv[])
{
  BOOL bIsWOW64 = FALSE;
  if ( IsWow64Process( GetCurrentProcess(), &bIsWOW64 ) && bIsWOW64 == TRUE )
  {
    LPCTSTR lpszFileToCreate = _T("C:\\windows\\system32\\wow64test.txt"); 

    // Create the file in C:\windows\syswow64 
    HANDLE hFile = CreateFile( lpszFileToCreate, GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
    CloseHandle( hFile ); 

    // Create the file in C:\windows\system32 
    PVOID pOldValue = NULL; 
    if ( Wow64DisableWow64FsRedirection( &pOldValue ) ) 
    { 
      HANDLE hFile64 = CreateFile( lpszFileToCreate, GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL ); 
      CloseHandle( hFile64 ); 
      Wow64RevertWow64FsRedirection( pOldValue ); 
    } 
  } 
  return 0; 
}

Die 64Bit Windows Artikel des eMCSCs

Dirk Eisenberg — Sat, 25 Feb 2006 18:12:00 GMT

Dank meinem Kollegen SKU wurde die Welt mit einer ganzen Serie 64Bit Windows Artikeln beglückt. Ich als ewig vergesslicher Mensch muss ständig in diesen Teilen etwas nachlesen. Leider stört das ewige Suchen im Blog jedesmal und strapaziert meinen ohnehin geringen Geduldsfaden. Aus diesem Grund habe ich die Teile als Linkliste hier zusammengetragen. Aus meiner Sicht sind diese Artikel Pflichlektüre für alle Entwickler die sowohl für die Microsoft Windows 32Bit als auch 64Bit-Plattform Software produzieren.

IBM Active Protection (2)

Dirk Eisenberg — Thu, 29 Sep 2005 04:45:00 GMT

Ich habe mal einen sehr spartanischen Prototypen zur IBM Active Protection implementiert. Mit diesem Tool ist es möglich die Bewegungen des Mouse-Pointers über die Neigung des Laptops zu steuern. Auf die Implementierung des Double-Click-Events haben ich verzichtet um größeren Schaden beim Testen zu vermeiden.

Download des MouseMovers hier und einen Screenshot des MouseMovers in Aktion.

IBM Active Protection

Dirk Eisenberg — Mon, 26 Sep 2005 07:09:00 GMT

Nach einer kräftigen Stärkung im Old-Country Buffet (ich liebe diese amerikanischen Buffets) habe ich etwas Zeit gefunden meine abendlichen Experimente mit der IBM Active Protection zu dokumentieren. Für alle interessierten Leser findet sich ein kleiner Artikel hier.

64 Bit Windows

Dirk Eisenberg — Fri, 23 Sep 2005 22:33:00 GMT

Ich möchte an dieser Stelle auf eine Blog Serie verweisen, die mein Kollege Stefan Kuhr begonnen hat. Hier bekommt man einen netten Einstieg in die derzeit von Microsoft unterstützten Tool und Techniken zur Entwicklung von Software auf 64Bit-Plattformen. Für jeden der noch nicht mit den Eigenheiten dieser Plattform vertraut ist, stellt diese Serie ein muss dar.

http://mcblogs.craalse.de/sku?cat=15