Soweit so schön, würde denn jetzt alles wieder wie üblich funktionieren. Tat es natürlich nicht. Jedes Mal wenn man sich bei Windows angemeldet hat, wurde man prompt wieder abgemeldet.

Auf der Suche nach dem Schuldigen

Die erste Analyse des Problems ist schnell abgeschlossen. Etwas muss sich in den Anmeldeprozess eingebunden haben, und wird nun jedes Mal beim Anmeldeprozess mit ausgeführt bzw. fehlt dank unserer Reinigung und der Anmeldeprozess schlägt deswegen fehl.

Möglichkeit 1:

Der Schädling hat die userinit.exe manipuliert und wird darüber gestartet. Sollte bei neueren Windows Versionen nicht mehr möglich sein, aber man weiß nie.

Kopiert die userinit.exe eines sauberen PCs in euer Windows\System32 Verzeichnis und startet den PC.  Nach der hoffentlich erfolgreichen Anmeldung, solltet ihr die Kommandozeile als Administrator, und mit folgendem Befehl eine Überprüfung der Systemdateien starten.

sfc /SCANNOW

Sollten weitere Dateien verändert worden sein, so müssten sie hierdurch erkannt und durch die richtigen Versionen ersetzt werden.

Möglichkeit 2:

Ein Trick der schon unter Windows 9x sehr beliebt bei Virenautoren war, ist die Liste der  zu startenden Programme zu erweitern. Bei Windows 9x musste man die win.ini bzw. system.ini ändern, ab Windows 2000 läuft das ganze jedoch über die Registry. Sucht den folgenden Schlüssel und prüft den Inhalt von Userinit.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Der Wert sollte normalerweise wie folgt lauten, achtet auf das Komma am Ende.

C:\WINDOWS\system32\userinit.exe,

Möglichkeit 3:

Eine weitere Möglichkeit, welche in diesem Fall zutraf, ist das starten als Debugger. Sobald das eigentliche Programm ausgeführt wird, wird unser Schädling mitgestartet.

Sucht in der Registry den folgenden Schlüssel und löscht ihn inkl. aller enthaltenden Werte.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Userinit.exe

Wollt Ihr Wissen an welcher Stelle sich der Schädling befindet, so findet Ihr den kompletten Pfad in dem Eintrag Debugger unterhalb des vorher genannten Schlüssels.

Wie soll ich die Registry ändern, ich kann mich gar nicht anmelden?

Das ist natürlich ein Problem. Normalerweise bearbeitet man mit regedit die Registrierung. Das steht uns leider nicht zur Verfügung, da die Anmeldung  selbst im abgesicherten Modus fehlschlägt.

Abhilfe schaffen die Ultimate Boot CD und die Ultimate Boot CD for Windows. Beide liefern Registry Editoren mit, die ein Anmelden an Windows unnötig machen.

Wie behebt man dieses Problem?

Im Grunde ist es ganz einfach, man muss lediglich eine Datei mit dem Namen desktop.ini in die Verwaltung kopieren und den folgenden Inhalt einfügen.

[LocalizedFileNames]
Memory Diagnostics Tool.lnk=@%SystemRoot%\system32\MdSched.exe,-4001
System Configuration.lnk=@%systemroot%\system32\msconfig.exe,-126
Performance Monitor.lnk=@%SystemRoot%\system32\wdc.dll,-10021
Data Sources (ODBC).lnk=@%SystemRoot%\system32\odbcint.dll,-1310
Windows Firewall with Advanced Security.lnk=@%SystemRoot%\System32\AuthFWGP.dll,-20
services.lnk=@%systemroot%\system32\filemgmt.dll,-2204
Computer Management.lnk=@%SystemRoot%\system32\mycomput.dll,-300
iSCSI Initiator.lnk=@%SystemRoot%\system32\iscsicpl.dll,-5001
Event Viewer.lnk=@%SystemRoot%\system32\miguiresource.dll,-101
Task Scheduler.lnk=@%SystemRoot%\system32\miguiresource.dll,-201
Component Services.lnk=@%systemroot%\system32\comres.dll,-3410
Print Management.lnk=@%systemroot%\system32\pmcsnap.dll,-700
Security Configuration Management.lnk=@%SystemRoot%\system32\wsecedit.dll,-718
[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21762

Wenn man anschließend die Verwaltung aktualisiert, erscheinen alle Links wieder in Deutsch (zumindest alle, für die es eine Übersetzung gibt).

Wie funktioniert das?

In den neueren Versionen von Windows, sind alle Ordnernamen und Verknüpfungen eigentlich in Englisch. Wer öfters mit der Kommandozeile arbeitet, wird dies sicherlich schon bemerkt haben. Der Ordner Benutzer heißt auf einmal Users, Programme heißt Program Files etc.

In der desktop.ini befinden sich die Pfade zu den entsprechenden Übersetzungen. Der Name für die Verknüpfung services.lnk befindet sich z.B. an Position 2204 in der Datei filemgmt.dll.

services.lnk=@%systemroot%\system32\filemgmt.dll,-2204

Das hat den Vorteil, dass bei Änderung der Desktop Sprache nicht alle Ordner und Verknüpfungen umbenannt werden müssen und alle Verweise innerhalb des Systems weiterhin funktionieren, da diese meistens auf die realen Ordnernamen verweisen.

Das gilt natürlich auch bei der Arbeit mit der Versionsverwaltung. Selbst wenn es sich um Git dreht, das man eigentlich nur auf der Konsole richtig nutzen kann. Nein, auch da muss eine GUI her, also greift man zu TortoiseGit.

Commit, Push, Pull, Log, alles kein Problem, aber schon mal versucht auf einem System mit TortoiseGit ein Repository/Projektordner zu löschen?

Wie „erfreulich“ diese Meldung doch ist, und dank TortoiseGit sieht man sie sogar regelmäßig. Was macht man jetzt? Wie bekloppt auf „Wiederholen“ klicken, bis es irgendwann klappt?

Das geht besser und zwar mit Unlocker. Unlocker bindet sich in das Kontext Menü eures Explorers ein, und erlaubt euch, Dateien wieder freizugeben.

Ein Klick auf „Unlocker“ öffnet nach einem kurzen Moment (und ggf. einer UAC Meldung) ein Fenster, in dem Ihr eine Auflistung aller in Benutzung befindlichen Dateien inkl. der schuldigen Programme findet.

Ein abschließender Klick auf „Alle Freigeben“ und das Repository lässt sich löschen.

Das Tool funktioniert natürlich auch, wenn ein anderes Programm Amok läuft und Dateien und Ordner sperrt. Passt bei der Installation auf, das Installationsprogramm versucht ein paar eBay Verknüpfungen auf eurem Desktop abzulegen. Diese könnt Ihr aber während der Installation abwählen.

Links:

• Unlocker (32 Bit) bei Chip.de
• Unlocker (64 Bit) bei Chip.de

Nachdem ich vor ein paar Tagen, im Rahmen des „Developers Shame Day“, in meiner Giftgrube gewühlt  und ein Code Schnipsel aus vergangenen Tagen veröffentlicht habe, kommt der heutige Beitrag wieder aus der Richtung „Was mache ich, wenn … ?“.

Während den Arbeiten an einem Projekt, testen wir die Seiten nicht nur mit verschiedenen Browsern, sondern auch mit verschiedenen Server Betriebssystemen. Wir wollen so gewährleisten, dass der Kunde einen Server seiner Wahl nutzen kann, ohne auf ein Feature verzichten zu müssen.

Ein Kollege sprach mich, nach solch einem Testlauf, darauf an, dass er Probleme mit Dateien hat, die er mittels Datei Upload in sein Windows Testsystem lädt. Beim Zugriff auf diese Dateien, wird er von Windows darauf aufmerksam gemacht, das er nicht die benötigten Rechte dazu besitzt.

Was ist passiert?

PHP speichert jede hochgeladene Datei in einem temporären Verzeichnis zwischen und gibt diese Information an das eigentliche PHP Skript weiter. Durch die Ablage im temporären Verzeichnis, gehen die Zugriffsrechte des Verzeichnisses auf die Datei über und bleiben auch nach evtl. Kopiervorgängen erhalten.

Sofern ihr den Pfad zum upload_tmp_dir nicht angepasst habt, wird das temporäre Verzeichnis eurer Windows Installation (C:\Windows\Temp) genutzt und für das habt ihr normalerweise keine Rechte.

Was kann man machen?

Um das Problem dauerhaft, und ohne Anpassung irgendwelcher Skripte zu beheben, stehen euch die folgenden drei Möglichkeiten zur Verfügung.

Möglichkeit 1:

Gebt dem Benutzer, der die Dateien weiterverarbeiten soll, die entsprechenden Rechte für das temporäre Verzeichnis. Zukünftige Dateien erben diese dann ebenfalls.

Möglichkeit 2:

Ändert in eurer php.ini den Wert von upload_tmp_dir und tragt ein Verzeichnis ein, für das ihr Zugriffsrechte habt.

Möglichkeit 3:

Legt euer Web Root und das temporäre Verzeichnis auf verschiedene Partitionen/Laufwerke. Durch das Kopieren auf eine andere Partition werden die Zugriffsrechte für die Datei automatisch erweitert.

Can’t move ‘.svn/tmp/entries’ to ‘.svn/entries’: The file or directory is corrupted and unreadable.

Wenn ihr diese oder eine ähnliche Meldung schon einmal gesehen habt, liege ich wahrscheinlich richtig, wenn ich behaupte, dass ihr Windows 7 oder eines der aktuellen Windows Serverbetriebssysteme im Einsatz habt.

Anders als die Meldung andeutet, ist die Datei aber weder beschädigt noch unlesbar, sie wurde lediglich vom System gesperrt, weil derzeit ein anderes Programm darauf zugreift. In einer Zeit vor Windows 7 lag es meist an Virenscannern, die Ihre Aufgabe erledigten und die Datei gescannt haben.

Seit Windows 7 hat aber meist der Indizierungsdienst schuld an der Meldung. Während ihr noch am ein- oder auschecken seid, versucht er eine Datei zu analysieren und blockiert sie dadurch. SVN kann die Datei deswegen nicht mehr öffnen, und bricht mit der bekannten Fehlermeldung ab.

Um Abhilfe zu schaffen, reicht es euren Projektordner aus der Liste der zu indizierenden Verzeichnisse zu nehmen. Öffnet hierzu euer Startmenü,  gebt in das Suchfeld Indizierung ein und bestätigt die Eingabe mit Enter. Es sollte sich ein Fenster mit dem Titel Indizierungsoptionen geöffnet haben.  Geht hier auf Ändern und sucht im neuen Fenster nach eurem Projektordner. Entfernt das Häkchen davor und bestätigt die Änderungen mit Enter.

Das Problem sollte sich nun erledigt haben, und jede neue Aktion mit Subversion sollte ohne Probleme vonstatten gehen.

• Klickt im Eclipse Fenster auf dem Pfeil, der neben dem Button zum Starten der externen Programme ist (Bild), und wählt “External Tools Configurations…” aus
• Klickt, in dem neu geöffneten Fenster, das Symbol für einen neuen Eintrag an (1)
• Gebt dem Eintrag einen Namen (2)
• Gebt unter Location (3) den Pfad zur explorer.exe an (${env_var:SystemRoot}\explorer.exe)
• Und unter Arguments (4), mit welchen Parametern der Explorer aufgerufen werden soll. Es empfiehlt sich /select,${resource_loc} dort einzutragen. Hierdurch wird das entsprechende Verzeichnis geöffnet und die ausgewählte Datei markiert.
• Speichert mit Apply und Close

Ihr habt jetzt einen neuen Eintrag bei den externen Programmen. Wählt nun eine Datei im Project bzw. Package Manager aus und klickt den Eintrag an. Der Windows Explorer sollte aufgehen und die Datei markiert sein.

Beim achten Schritt meldet der Assistent, das eine Ausnahme vom Typ Microsoft.Office.Server.UserProfiles.UserProfileException aufgetreten ist und er das Attribut allowInsecureTransport nicht kennt. Der Assistent beendet sich und bittet um die Behebung des Problems.

Microsoft bietet über Microsoft Connect einen entsprechenden Hotfix an, der das Problem behebt. Nach der Installation muss man den Assistenten über das Startmenü noch einmal starten.

• Windows 7, Windows Server 2008 R2

Um diese zu betreten, erstellt einfach einen neuen Ordner und vergebt den folgenden Namen:
(GodMode könnt ihr durch einen beliebigen Text ersetzen, der Rest muss so bleiben)

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Das Symbol sollte sich nun ändern, und nach einem Doppelklick darauf, öffnet sich die versprochene Übersicht.

Installation:

• Ladet Fake Sendmail herunter und entpackt die sendmail.exe und sendmail.ini in ein Verzeichnis eurer Wahl (z.B. c:\sendmail)
• Öffnet die sendmail.ini und sucht nach der Option smtp_server. Setzt den Wert, auf einen existierenden Pfad (z.B. c:\sendmail\mails).
• Sucht default_domain und setzt den Wert auf die gewünschte Standard Domain (z.B. localhost)
  
  Beispiel:

  smtp_server=c:\sendmail\mails
  default_domain=localhost

• Öffnet eure php.ini und prüft ob die Einträge SMTP und smtp_port auskommentiert sind.
• Nun sucht sendmail_path und setzt dort den Pfad zum Sendmail Programm, sowie den Parameter -t
  Beispiel:

  ;SMTP = localhost
  ;smtp_port = 25
  sendmail_path = "C:\sendmail\sendmail.exe -t"

Der E-Mail Versand unter Windows sollte nun funktionieren.

Links:

• Fake Sendmail