• Da arbeitet man 4, 8, 12 oder 16 Stunden an einem Modul.
• Alles sieht gut aus, nicht mehr lange und wir können einchecken.
• Du änderst noch dies und das, steckst noch mal 2 Stunden Arbeit rein weil noch was optimiert werden soll und auf einmal merkst Du dass Du Dich verrannt hast. Die letzten 2 Stunden Arbeit hattest Du irgendwie das Gehirn nicht eingeschaltet, x-Änderungen gemacht, die nun alle Sch…sind.
• Undo ist nicht mehr, weil Du schon andere Projekte offen hattest bzw. einmal VS abgeraucht ist.
• Du hast Bockmist gebaut und jetzt willst Du auf den Stand von vor 4 Stunden zurück, oder den von gestern Abend.
• Ein Shelveset hast Du im TFS nicht angelegt. Das machst Du nur wenn Du ins Wochenende gehst, oder Deinen Kollegen was weiterreichen musst.

Was nun?

Als VA-X Benutzer (VisualAssist X http://www.wholetomato.com) hat man tatsächlich noch ein Backup!
Und zwar nicht nur eines, sondern ein paar.
In meinem History Ordner von VA-X
C:\Users\USER\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Whole Tomato Software\Visual Assist X\VERSION\Data\vs10\history\
werde ich fündig…

Ufff…

Ich habe dieses Backup mittlerweile schon so oft verwendet, dass ich dazu übergangen bin diesen Ordner umzulegen an eine Stelle an die ich schneller dran komme. Das geht über den Registry Schlüssel HKCU\Software\Whole Tomato\UserDataDir.

Wer mehr dazu wissen will findet hier weitere Infos:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=6865

Nachtrag (30.01.2012):
Damit diese Funktion auch verfügbar ist muss im VA-X die Auto Recovery Option eingeschaltet sein.
VA-X -> Options -> Performance -> Enable Auto Recovery

VS-2010 installiert eine Unmenge an Komponenten und Programmteilen. Die meisten können einfach deinstalliert/gelöscht werden. Aber es bleiben immer noch ein Haufen DLLs/ActiveX Controls und Registry Einträge und Verweise auf Verzeichnisse. Und leider gibt es für die Visual Studio 2010 keinen richtigen Uninstaller, der auch alle Artefakte löscht und deshalb kann ich gleich zu Anfang sagen, dass man außer der Deinstallation wirklich wenig tun kann.
Eine Reparaturinstallation sollte man aber bei einer bestehenden Installation in jedem Fall einmal, bevor man zu härteren Maßnahmen greift. Die wirkt oft schon Wunder.

Im Netz gibt es das folgende Utility: Visual Studio 2010 Uninstall Utility:
http://archive.msdn.microsoft.com/vs2010uninstall
Das Tool hat drei Operationsweisen die man in dem obigen Link erklärt findet.
Das Tool funktioniert eigentlich ohne Probleme aber benutzt auch nur auf dem MSI Uninstall Prozess auf, und dabei berücksichtigt es nicht einmal Servicepacks. Sollte man also das SP1 von Visual Studio 2010 installiert haben, dann muss man dieses vorher selber entfernen.

Das dieses Tool macht aber auch nur die Arbeit halb. Das erkennt man mit einem schnellen Blick in Registry. Der Ast HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0 wird durch die Deinstallation nicht entfernt und man muß in diesem Fall manuell Hand anlegen.

Wenn man also persistente Probleme mit der VS-2010 Installation hat, die man nicht über die Setup-Logs oder mit Tipps aus den Foren lösen kann, dann bleibt nach meiner Meinung nur der harte Weg den Rechner neu aufzusetzen. Bisher bin ich davon verschont geblieben und meine Installation haben immer von Rechnerwechsel zu Rechnerwechsel gehalten.

Die Ursache lag aber in dem neuen Nvidia GeForce Treiber 285.62 (Windows 7, 64bit). Mit diesem dem hat auch bei der Wiedergabe einer Aufzeichnung kein Bild.  Nun bin ich auf den Treiber Stand 280.26 zurück gegangen und alles ist wieder gut.

Da ich nicht Zocke spielen, die neuen Features dieser Treiberversion für mich sowieso keine große Rolle.

Soweit ist alles gut abgelaufen, der SQL Server läuft. Einzig die Reporting Services ließen sich nicht mehr starten. Die Reporting Services liefen allerdings zuvor ohne Probleme.

Eine Reparaturinstallation sowie Entfernen und erneutes Hinzufügen des Dienstes wurden ohne jedweden Erfolg durchgeführt.

Nach dem fehlgeschlagenem Start des Dienst fanden sich nur die drei folgenden Einträge im Event-Log:

Protokollname: Application
Quelle:        SQL Server Reporting Services (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   0
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Der Dienst kann nicht gestartet werden. System.Exception: Default appdomain failed to initialize.
bei Microsoft.ReportingServices.Library.ServiceAppDomainController.Start()
bei Microsoft.ReportingServices.Library.ReportService.OnStart(String[] args)
bei System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)

Protokollname: Application
Quelle:        Report Server Windows Service (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   140
Aufgabenkategorie:Starten/Herunterfahren
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Fehler beim Initialisieren der DefaultDomain-Anwendungsdomäne. Fehler: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt..

Protokollname: Application
Quelle:        Report Server Windows Service (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   113
Aufgabenkategorie:Protokollierung
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Der Berichtsserver kann den Leistungsindikator 'Report Requests' nicht erstellen.

Der letzte Eintrag mit der Meldung “Der Berichtsserver kann den Leistungsindikator ‘Report Requests’ nicht erstellen.”, in Verbindung mit der Meldung “System.Exception: Default appdomain failed to initialize.” . Hat mich letzten Endes auf die Spur gebracht.

Die Lösung ist hier zu finden: http://support.microsoft.com/kb/956155/en-us

Offensichtlich wurde bei der Deinstallation des 2008er SQL-Servers mehr entfernt als gut war und der hier vorgeschlagene Weg einer Reparaturinstallation war leider nicht erfolgreich.
Ich habe die 4 Schlüssel die fehlten einfach manuell eingefügt und der Dienst konnte danach sofort wieder gestartet werden.

In meinem Fall waren es folgende Devices, die ich in meinen virtuellen Maschinen benötigte:

• Unseren Master-Dongle für die Dongleerzeugung (WiBu)
• Ein USB-Modem für unseren Fax-Eingang
• Ein USB-Seriell Adapter an der eine TK-Anlage angeschlossen ist und gesteuert wird
• Ein weitere USB-Port nochmal für eine weitere TK-Anlage
• Manchmal für den direkten Anschluß einer USB Festplatte/Sticks

Ich habe mir einige Lösungen angesehen, die alle die USB-Devices über das Netzwerk sharen. Manche sind spezielle USB-Hubs mit Netzwerkanschluss, andere reine Software Lösungen.

Im Einsatz ist nun USB over Ethernet von KernelPro als reine Softwarelösung gekommen.
Bei dieser Lösung wird auf dem Hyper-V Host nur die Server Komponente installiert. Am Host schließt man nun die gewünschten USB Geräte an, ohne deren Treiber zu installieren. Man wählt in der Server Software nun die USB Geräte aus, die über das Netzwerk an interne Server weitergereicht werden.
Auf dem internen virtuellen Server, wird nun die Client-Software installiert. Dort kann mannun die USB Geräte auswählen, die der Server zur Verfügung stellt und die man in der virtuellen Maschine benötigt. Entsprechende Portfreigaben in der Firewall sind natürlich zu beachten. Auf dem virtuellen Client werden nun wie gewohnt die USB-Treiber installiert.
USB over Ethernet läuft als Dienst sowohl als Client wie auch als Server. Man muss sich um nichts mehr kümmern, alle angeschlossenen Geräte werden auch bei entsprechenden Serverneustarts einfach durchgereicht wenn die Dienste wieder starten.

Die Oberfläche des Tools ist einfach und verständlich ohne Schnickschnack wie man sich das für ein Server-Tool wünscht, dazu ist der Speicherverbrauch und die Prozessorlast niedrig. Die Software läuft seit 2 1/2 Monaten unauffällig und stabil, wie es sein soll.

Unter Windows 2000 kann man wie folgt vorgehen und das Problem beheben:

1. Am Besten macht man das nachdem man das System neu gestartet hat und noch keine Anwendung gestartet hat.
2. Alle betreffenden Hotfixe entfernen (für Runtime-2005 KB2467175, Runtime-2008 KB2467174, für VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).
   Die betroffenen C/C++ Runtimes des Visual Studio, die deinstalliert werden müssen, haben die folgenden Versionsnummern
   - VC-2005 8.0.50727.5592 (KB2467175)
   - VC-2008 9.0.30729.5570 (KB2467174)
   Um VS-2005/2008 wiederherzustellen ist zwingend eine Deinstallation des Patches nötig.
   Die Dateien für das Visual Studio sollten dann wieder denen des letzten Fix aus 2005/2008 entsprechen.
3. Eigentlich sollte die Deinstallation des Patches genügen.
   Sofern es sich nur um ein Problem mit den Runtimes handelt und sich das Problem nicht behoben hat kann man mit den nächsten Schritten weiter machen und versuchen die alten Dateien wieder herzustellen.
   (Man kann diese Schritte auch ohne Deinstallation durchführen)
4. Für VS-2008: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
   a. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_…
   b. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4148_…
   c. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_…
   Man wählt das Verzeichnis, dass man zuerst findet.
5. Für VS-2005: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
   a. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_…
   b. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4027_…
   c. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.1833_…
   d. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_…
   Man wählt das Verzeichnis, dass man zuerst findet.
6. Alle Dateien aus diesen gefundenen Verzeichnissen in das C:\WinNT\System32 Verzeichnis kopieren.

Hope that helps

PS: Ich habe den Artikel mehrfach überarbeitet während er bereits veröffentlicht war und immer neue Infos eingebaut bzw. die Vorgehensweise besser erklärt.

1. Massive Thread-Handle Leaks bei asnychronen Operationen:
   ADO, adAsyncExecute and Windows 7 SP1 handles leaking
   http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/68e23681-f6b5-4ed5-b963-e63e34eeac2f
   Dieser Bug wurde bereits von Microsoft bestätigt.
   Wer einen Fix braucht muss sich an den Microsoft Support wenden.
2. Das zweite Problem betrifft die COM Registrierung für Applikationen, die auf Windows 7 SP1 Maschinen gebaut werden.
   Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1
   http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13
   Siehe auch:
   http://blogs.technet.com/b/asiasupp/archive/2011/03/14/changes-in-mdac-adodb-com-components-in-windows-7-service-pack-1.aspx

PS: Ich bin ziemlich froh, dass ich direkt auf OLD-DB arbeite…

Auf diesem Rechner wie auf auf zwei anderen meiner Rechner benutze ich eine Microsoft Keyboard-Maus Kombination. Entsprechend ist auf den Rechnern auch Microsoft IntelliType und IntelliPoint installiert.

Alles lief beim Update von Windows 7 glatt. Aber nach dem Neustart des Systems bekam ich einen UAC Prompt und es wurde gemeldet, dass ein neuer USB Treiber für die Microsoft Tastatur installiert werden müsste. Also OK.

Aber beim nächsten Neustart wieder die gleiche Meldung, ein detailierter Blick auf den Treiber der angefordert wurde ergab folgende Info:

rundll32.exe C:\Windows\system32\newdev.dll,pDiDeviceInstallAction \\.\pipe\PNP_Device_Install_Pipe_1.{541e93b9-2da1-4d96-91e1-68472a06f5a9} “usb\vid_045e&pid_00e3&mi_00\7&13cc06b7&0&0000″

Neuinstallation/Reparaturinstalltion der IntelliType Software nützte nichts.

Erst als ich die Software komplett entfert hatte und dann eine Neuinstalltion durchgeführt habe verschwand diese lästige Meldung.

Entfernen der SP1 Backupdateien für Window 7

Dazu startet man einfach die Datenträgerbereinigung (CLEANMGR.EXE) als Administrator. Oder man startet die Datenträgerbereinigung normal und klickt dann auf den Schalter Systemdateien bereinigen. Nur wenn man das Programm als Admin startet erhält man auch Zugriff auf die Backupdateien des SP1.
Bei mir wurden hier zwischen 0,5GB und 0,8GB freigegeben.

Entfernen der SP1 Backupdateien für Windows Server 2008 R2

Das Löschen der Backup Dateien des SP1 für einen Windows Server 2008 R2 ist hier beschrieben:
http://technet.microsoft.com/en-us/library/ff817650(WS.10).aspx (ziemlich weit unten unter To remove service pack backup files).

Der Befehl zum Entfernen der Backupdateien für ein durchgeführtes Online-Update lautet entsprechend:
DISM.exe /online /Cleanup-Image /spsuperseded

bzw. bei Verwendung eines Offline-Images:
DISM.exe /Image:<path_to_offline_image> /Cleanup-Image /spsuperseded

Auf meinen Servern konnte ich durch diese Operation im Schnitt ca. 2,4GB freigeben.

Nachtrag (09.03.2011):
Es sollte klar sein, dass man die Installation des SP1 nach Löschen der Backup-Dateien nicht mehr rückgängig machen kann.

Dann bin ich auf die Idee gekommen mal unsere Antiviren Software (Symantec Endpoint Protection) auszuschalten. WOW… Die OfficeLine startet in nicht weniger als 3 Sekunden

Jetzt habe ich einfach die beiden Dateien “C:\Program Files\Sage\Office Line\4.2\Abf\OLABF_001.ADE” und “C:\Program Files\Sage\Office Line\4.2\Rewe\OLREWE_001.ADE“, der Warenwirtschaft bzw. des Rechnungswesen durch eine extra Regel in der Endpoint Protection ausgenommen und siehe da alles gut.

Die Endpoint Protection kenne ich sonst nicht so als Systembremse, aber wie man sieht lohnt sich manchmal ein kritischer Blick auf das eigene AV System.