WelliSolutions

WelliSolutions macht Elternpause zur Geburt unseres zweiten Sohnes. Vom 12.1.2013 bis 11.3.2013 müssen Sie leider auf unsere Dienstleistungen verzichten. Ab dem 12.3.2013 sind wir gern wieder für Sie da.

Hinweis: das Gewerbe wurde für diese Zeit abgemeldet. Auskünfte bei der Gemeinde Königsfeld werden entsprechend negativ beantwortet.

Ein besonderes Tool um CDs oder DVDs zu retten ist das kostenlose Programm h2cdimage. Die Besonderheit dabei ist, dass das Programm darauf ausgelegt ist, die defekte (z.B. zerkratzte) CD/DVD auf mehreren Laufwerken zu lesen und die Informationen dann zusammenzufassen, um möglichst viele Daten retten zu können.

Die Bedienung ist jedoch nicht ganz einfach, denn abgesehen davon, dass es sich um ein Programm für die Kommandozeile handelt, benötigt man für das Retten einer CD/DVD drei Angaben, nämlich den Adapter, das Target und die LUN.

Mit Windows 7 lassen sich diese Angaben ermitteln, wenngleich nicht direkt als Zuordnung zum Laufwerksbuchstaben. Im Explorer öffnet man das Kontextmenü des CD/DVD-Laufwerks und wählt Eigenschaften. Dann wechselt man auf das Tab “Hardware”. Hier sind alle Laufwerke aufgelistet. Leider wird automatisch der erste Eintrag in der Liste ausgewählt und nicht der zum Laufwerksbuchstaben gehörende Eintrag.

Im Bereich “Geräteeigenschaften” werden unter “Ort” die erforderlichen Angaben aufgelistet. Channel ist dabei gleichbedeutend zu Adapter. Mit diesen Angaben lässt sich h2cdimage starten und die Daten der defekten CD oder DVD hoffentlich wieder vollständig rekonstruieren.

Adapter, Target, LUN

Hat Ihnen diese Seite geholfen, Daten einer CD oder DVD zu retten? Falls ja, spenden Sie doch einen Betrag an mich, der mich motiviert, auch zukünftig Informationen dieser Art bereitzustellen. Vielen Dank!

Brauchen Sie weitere Hilfe bei der Rettung von Daten auf CDs oder Festplatte? WelliSolutions rettet Ihre Daten – speziell abends oder am Wochenende sind wir gern für Sie da, wenn Sie von der Arbeit heimkommen und andere Firmen nicht mehr zur Verfügung stehen. Rufen Sie an unter 07725/915646. Schwarzwald-Baar-Kreis und Rottweil gehören zu unserem typischen Einzugsgebiet.

Macht eine Festplatte seltsame Geräusche oder startet gar nicht mehr, so müssen professionelle Center für Datenrettung helfen, wie bei dieser Festplatte aus einem Laptop. Datenrettungen sind jedoch sehr teuer und mit 1000 € für eine Privatperson nicht zu leisten.

Besser Sie lassen es gar nicht so weit kommen und fertigen regelmäßig eine Sicherungskopie an. Wann haben Sie zuletzt ein Backup erstellt? Tun Sie es lieber heute anstatt morgen. Lassen Sie sich von WelliSolutions zu einer Backup-Strategie beraten.

Wer Web-Analytics betreibt darf sich auf die ein oder andere Überraschung gefasst machen oder über seltsame Phänomene nachdenken wie in diesem Fall: Obwohl Yahoo angibt, keine Seiten der betreffenden Webseite indexiert  zu haben, kamen 3 Besucher über Yahoo auf die Webseite. Da fragt man sich schon, wie das sein kann.

Nicht indexiert

Ab und zu hatte ich das Problem, dass Tortoise (eine grafische Oberfläche für Subversion) gewisse Operationen nicht durchführen kann. Dann schlägt es vor, das Cleanup-Kommando auszuführen. Cleanup selbst meldet dann jedoch Fehler. Abhilfe schafft das Anlegen der fehlenden Verzeichnisse in den Verwaltungsstrukturen von Subversion (.svn-Ordner). Bei tiefen Verzeichnisstrukturen hat man jedoch allerhand zu tun.

SVN commit failed

Zuletzt trat der Fehler bei mir in einer sehr tief verschachtelten Ordnerstruktur auf, so dass ich zu anderen Mitteln greifen musste: einer Batch-Datei, welche die Korrektur rekursiv vornimmt.

@echo off
REM Remove quotes for now, otherwise we have it duplicated in the for loop
set "folder=%~1"
set "file=%~2"
REM Default folder is current directory
if "%folder%"=="" set folder=.
REM If SVN directory is found, go and fix it
if "%file%"==".svn" goto fixsvn
REM Process subfolders
for /f "delims=" %%d IN ('dir /ad /w /b "%folder%"') DO call %0 "%folder%/%%d" "%%~d"
goto ende
:fixsvn
echo "Fixing %folder% ..."
mkdir "%folder%/props" 2> NUL
mkdir "%folder%/prop-base" 2> NUL
mkdir "%folder%/text-base" 2> NUL
mkdir "%folder%/tmp" 2> NUL
mkdir "%folder%/tmp/prop-base" 2> NUL
mkdir "%folder%/tmp/props" 2> NUL
mkdir "%folder%/tmp/text-base" 2> NUL
:ende
Diesen Code einfach in eine Batch-Datei einfügen, die Batch-Datei in den beschädigten Ordner legen und ausführen. Die Batch-Datei ermittelt dann selbstständig alle .svn-Ordner und legt fehlende Unterverzeichnisse an. Warum das nicht im Cleanup-Kommando eingebaut ist weiß ich nicht. Das Problem besteht zumindest schon seit 2006, wie ein Bug-Eintrag zeigt.

Update 2012-01-10: Verbesserte Ausgabe. Die Datei hilft übrigens auch bei einem missglückten “Upgrade Working Copy” beim Update auf Tortoise 1.7, wenn ein Cleanup gar nicht mehr zur Verfügung steht.

Update 2012-01-12: Fehler behoben: Script funktioniert jetzt auch, wenn die SVN-Struktur Ordner mit & enthält. Etwas mehr Anführungszeichen haben geholfen.

Hat Ihnen dieser Artikel geholfen, Ihre Probleme zu lösen? Falls ja, spenden Sie doch einige Kleinigkeit an mich, damit ich motiviert bin, auch zukünftig Informationen dieser Art bereitzustellen. Vielen Dank!

Ab und zu kommt es zu unvorhergesehenen Defekten der Hardware: im obigen Beispiel der Defekt eines bis dato zuverlässigen USB-Sticks. Das Einpacken des Laptops in die Laptop-Tasche bei angetecktem USB-Stick hat den Defekt verursacht.

Gut, wenn man regelmäßig Backups erstellt – nicht nur von der Festplatte des Rechners, sondern auch von Wechseldatenträgern.  Am besten jetzt gleich – nicht erst morgen.

Situation

Ein in Blender modellierter 3D Körper soll in einem Bildbearbeitungsprogramm weiterverarbeitet werden. Insbesondere soll dabei die Tiefeninformation ausgewertet werden.

Problem

Blender kann das gerenderte Bild inklusive Alpha-Kanal und Z-Buffer nur in einem bestimmten Format speichern, nämlich OpenEXR. Alle anderen Dateiformate unterstützen keine Z-Buffer.

Lösung

Über den Compositor lassen sich die Z-Buffer Informationen weiter verarbeiten und als PNG Grafik speichern. Die notwendigen Knoten und Verbindungen sind:

1. vom Render Layer Z Ausgang zum Normalize Eingang (Knoten: Vector Normalize).
2. vom Normalize Ausgang zum Invert Color Eingang (Knoten: Color/Invert).
3. vom Invert Ausgang zum Viewer Image Image Eingang (Knoten: Output/Viewer)
4. zum Abspeichern: vom Invert Ausgang zum File Output Image Eingang (Knoten: Output/File Output)

Übersicht

Compositor

Weiterverwendung

Links

BlenderGuru (rev. 2011-06-15) liefert viele Informationen zum Blender Compositor

WelliSolutions ist umgezogen.

Neue Adresse von WelliSolutions (gültig seit 1.3.2011):

WelliSolutions
Thomas Weller e.Kfm.
Hutzelweg 22
78126 Königsfeld

Sofern Sie postalisch mit uns in Kontakt sind, ändern Sie bitte unsere Post-, Rechnungs- und Lieferadresse. Vielen Dank.

Ausgedient

Bisherige Adresse von WelliSolutions (gültig bis 1.3.2011):

WelliSolutions
Thomas Weller e.Kfm.
Käppelestr. 13
78166 Donaueschingen

Situation

Ein .NET Programm startet langsam. Ich bin mit der Zeit nicht zufrieden. Als Ursache vermute ich das .NET Framework selbst. Das Laden des .NET Frameworks mit all seinen DLLs dauert einige Zeit.

Lösungsansatz

Beim Start des Rechners könnte ein .NET Programm geladen werden, beispielsweise als Programm im Autostart-Ordner. Dadurch befinden sich die benötigten DLLs bereits im Speicher und die folgenden Anwendungen können auf die bereits geladenen DLLs zugreifen. Außerdem basieren vermutlich immer mehr Anwendungen auf dem .NET Framework, so dass mehrere Programme davon profitieren.

Lösungsbewertung

Doch was bedeutet das für den PC? Zunächst einmal verzögert sich der Startvorgang des PCs. Im Gegenzug verbessert sich der Startvorgang des betroffenen Programms.
Weiterhin ist fraglich, welche DLLs geladen werden sollen. Ein maßgeschneidertes Programm hat den Vorteil, dass nur die DLLs geladen werden, die das betroffene Programm dann tatsächlich auch nutzt. Beim generellen Laden von allen DLLs profitieren sämtliche Programme. Da ich vermute, dass es mehrere .NET Programme gibt, habe ich mich zur weiteren Analyse des generellen Ansatzes entschieden.

Beim generellen Ansatz durchsuche ich das Verzeichnis C:\Windows\assembly\GAC_MSIL (dort befinden sich die .NET 2.0 DLLs) rekursiv und ermittle alle enthaltenen DLLs. Dann versucht das Programm, die DLL als Assembly zu laden. Gelingt dies, wird das Assembly einer Liste hinzugefügt. Gelingt es nicht, dann war die DLL möglicherweise keine .NET DLL oder eine .NET DLL in der falschen Frameworkversion.

Eine Übersicht über den Speicher verschaffe ich mir mit dem Tool SysInternals VMMap (rev. 2011-03-07). Das erstellte Programm belegt nach dem Laden aller DLLs 530 MB Speicher (Committed). Davon werden jedoch ca. 470 MB gleich wieder ausgelagert, so dass nur ca. 60 MB im RAM (WorkingSet) verbleiben.  DLLs sind in dieser Auflistung unter “Image” angegeben (siehe Grafik).

Das bedeutet: es wurden 530 MB von Platte gelesen und 470 MB wieder auf Platte geschrieben. Je nach Geschwindigkeit der Festplatten dauert das beträchtlich lange. Hinzu kommt noch die Zeit, die benötigt wird, um die Assemblies zu initialisieren. Auf meinem Rechner ist das Laden erst nach über 2 Minuten abgeschlossen. Doch welchen Effekt hat dies nun auf das betroffene Programm?

Auch auf diese Frage gibt es eine Antwort von VMMap: die Bytes, die sich die Anwendung mit anderen Anwendungen teilen kann, sind unter “Shareable WS” aufgelistet. Die Angaben sind plausibel und erwartet: am meisten Speicher können sich Anwendungen über Dateien teilen. In der Grafik werden unmittelbar nach dem Start ca. 51 MB an teilbaren DLLs ausgewiesen.

Doch dieser Wert ist mit Vorsicht zu genießen, denn das WorkingSet verändert sich ständig. Wenn Windows für andere Anwendungen mehr Speicher benötigt, lagert es weiter auf die Festplatte aus. Dadurch verringert sich das WorkingSet und somit auch die Anzahl an teilbaren Dateien. Im bisher ungünstigsten von mir beobachteten Fall sank das WorkingSet auf 2,8 MB, was den Performancegewinn komplett zunichte macht.

VMMap

Ungünstig

Doch all das sind nur theoretische Anhaltspunkte. Gibt es vielleicht doch eine spürbare Verbesserung beim Start des betroffenen Programms? Auch hier sind ein paar Rahmenbedingungen zu beachten: einerseits lässt sich das Verhalten nur richtig beim “Kaltstart” des Programms beobachten. Beim “Warmstart” befinden sich ggf. viele Dateien noch im Cache des Betriebssystems. Also sollte der PC zwischen zwei Tests neu gebootet werden.

Damit das Ganze nicht so subjektiv ist, habe ich eine kleine Batchdatei entwickelt, welche die Dauer zum Laden eines .NET Programms misst. Die Batchdatei gibt einfach die Zeit vor und nach dem Start der Anwendung an.

@echo off
echo | time
start /wait simplewinforms.exe
echo | time
pause

Das .NET Programm zeigt ein leeres Fenster an, wartet auf das “Shown” Event und beendet sich dann sofort wieder.

public Form1()
{
    InitializeComponent();
    Shown += OnShown;
}
private void OnShown(object sender, EventArgs e)
{
    Close();
}

Mit diesen Mitteln ausgestattet habe ich meinen Rechner drei Mal je Konfiguration neu gestartet. Nach dem Anmelden habe ich gewartet, bis die Festplattenlampe nicht mehr leuchtete, 30 Sekunden zusätzlich gewartet und dann die Batch-Datei gestartet. Den ganzen Ablauf habe ich einmal ohne das Ladeprogramm und einmal mit dem Ladeprogramm abgearbeitet.

Im dritten Durchgang habe ich simuliert, was passiert, wenn in der Zwischenzeit viele Programme gestartet werden. Dazu habe ich vor Start des .NET Programms ein C++ Programm gestartet, welches 1,3 GB Speicher anfordert (bei 2,0 GB physikalischem RAM), wieder freigibt und dann auf einen Tastendruck wartet. Die Erwartung ist, dass das WorkingSet des .NET Ladeprogramms stark verringert wird und dadurch die Performance-Auswirkungen geringer sind.

int main(int argc, char* argv[])
{
    void *buffer;
    buffer = malloc(1300000000);
    if (buffer==NULL)
    {
        printf("malloc failed");
        getch();
        return 1;
    };
    free(buffer);
    printf ("Press a key.");
    getch();
    return 0;
}

Hier die Ergebnisse ohne Ladeprogramm:
3,11 Sekunden
3,57 Sekunden
3,62 Sekunden

Und die Ergebnisse mit dem Ladeprogramm:
1,00 Sekunden
0,98 Sekunden
1,03 Sekunden

Bei der Simulation von mehreren Programmstarts (und freigegebenem Speicher):
1,87 Sekunden
1,95 Sekunden
1,82 Sekunden

Bei der Simulation von mehreren Programmstarts (und belegtem Speicher):
- noch keine Messergebnisse -

Wie sieht es eigentlich mit der Vermutung aus, dass immer mehr Programme mit .NET entwickelt werden? Das Tool der Wahl ist hier der SysInternals Process Explorer (rev. 2011-03-07). Über Options/Configure Highlighting kann eingestellt werden, wie Programme eingefärbt werden. Da unklar ist, welche Prioritäten die Farben haben, wählt man am besten nur .NET aus. Diese werden dann gelb markiert. So ausgestattet stelle ich auf meinem PC fest, dass nach dem Booten überhaupt kein .NET Programm aktiv ist. Zumindest auf meinem PC trifft die Vermutung also nicht zu. Ansonsten müsste das betroffene Programm ja auch bereits von den anderen Programmen profitieren, da ein Teil der DLLs schon geladen sein müsste.

Schwachstellen der Analyse

RAM wird immer billiger. Bei einer entsprechenden Ausstattung an RAM könnte die Auslagerungsdatei komplett abgeschaltet werden. Dann werden alle Daten zwangsläufig im RAM gehalten und der Performancegewinn müsste deutlich höher ausfallen. Doch selbst bei 8 GB RAM frage ich mich, ob ich gleich 500 MB davon nur für das Laden von .NET DLLs opfern soll.

Das gestartete Programm verwendet außer seiner eigenen DLL nur DLLs, die tatsächlich auch vom Ladeprogramm vorgeladen werden. Andere Programme laden jedoch typischerweise noch weitere 3rd-Party DLLs, die nicht vom Ladeprogramm erfasst werden. Für diese DLLs ergibt sich kein Performancegewinn.

Die Simulation von Programmstarts (Belegung von 1,3 GB Speicher) gibt den Speicher wieder frei. Dadurch trifft das zur Messung verwendete .NET Programm bei seinem Start auf 1,3 GB frisch freigegebenen Speicher und profitiert dadurch vermutlich, weil es nicht zuerst andere Programme auf Platte auslagern muss. Im realen Betrieb dürfte der Peformancegewinn schlechter ausfallen.

Fazit

Es ist schwierig, die Vor- und Nachteile des Ladens aller .NET Framework DLLs beim Start des PCs zu beurteilen. Wie die Untersuchungen zeigen, hängt ein möglicher Performancegewinn von vielen Faktoren ab, bei denen es schwer fällt, eine objektive Aussage zu treffen. Die gemessenen Zeiten zeigen jedoch, dass durch ein systematisches Vorgehen wenigstens reproduzierbare Ergebnisse ermittelt werden können.

Abhängig vom Benutzerverhalten (früher oder später Start des betroffenen Programms), vom verfügbaren Speicher (RAM) und von der speziellen Optimierung des Ladeprogramms auf das Problem lassen sich unterschiedliche Performancegewinne beobachten, die jedoch in jedem Fall negativen Einfluss auf die Bootzeit des Rechners haben.

Falls Sie Untersuchungen auf Ihrem eigenen System durchführen möchten, stelle ich in den nächsten Tagen die Programme im Quellcode und als ausführbare Programme bereit. Die Untersuchungen sowie Programme sind für 32 Bit Betriebssysteme ausgelegt, sollten aber auch in einer 64 Bit Umgebung im WoW64-Modus laufen.

Situation

Passwörter gibt es heute fast überall, beinahe jede Webseite benötigt einen Login. Wir bei WelliSolutions verwenden KeePass, um Passwörter zu verwalten. Die Passwörter werden verschlüsselt abgelegt. Um die verschlüsselten Passwörter zu lesen benötigt man wieder ein Passwort – aber eben nur noch ein Passwort, um Zugriff auf alle Passwörter zu erlangen.

Außerdem bietet KeePass auch Schutz vor anderen Angriffen auf Passwörter, wie auf der KeePass Homepage (rev. 2009-11-08) zu lesen ist: “All security features in KeePass protect against generic threats like keyloggers, clipboard monitors, password control monitors, etc. ”

Problem

Ein kleines Programm zeigt, dass dem nicht so ist. Innerhalb einer halben Stunde konnten wir ein Programm schreiben, welches nur darauf wartet, dass KeePass einen Text (typischerweise einen Benutzernamen oder Passwort) in die Zwischenablage kopiert.

Lösung

Das Problem wurde dem Autor der Software, Dominik Reichl, mitgeteilt. Er hat das Problem bestätigt, sieht aber leider keine Verbesserungsmöglichkeiten. Inzwischen wurde die Angabe zur Sicherheit ergänzt um den Zusatz “However in all the questions above we’re assuming that there’s a spyware program running on the system that’s specialized on attacking KeePass.”

Für WelliSolutions stellt sich die Frage, wie viele unterschiedliche Passwort-Verwaltungssysteme es gibt und ob es zu schwierig wäre, spezielle Attacken für alle zu implementieren.

Links

KeePass Password Safe Homepage (rev. 2011-02-18)