Schlagwort: Windows 7

Bug: VC-2010 MFC CFormView zeichnet Buttons beim Rollen falsch, es erscheinen schwarze Blöcke

In der MFC 10.0 hat sich ein Bug eingeschlichen, der sich unter Windows Vista und Windows 7  bemerkbar macht. Unter Windows XP tritt der Fehler nicht auf. Das Problem tritt in jedem Stil auf, der DWM verwendet. D.h. nicht wenn Windows klassisch ausgewählt wird.

Wenn auf einen CFormView mehrere Buttons liegen und der CFormView gerollt wird, dann kommt es unter Umständen zu Fehlern beim Neuzeichnen von Buttons. Dies schließt alle Button-Formen ein: Check-Buttons, Radio-Buttons und normale Buttons.

Das Ganze sieht nach dem Rollen in etwa so aus:

Der Text einiger Buttons erscheint nach dem Rollen als schwarze Blöcke. Es kann auch vorkommen, dass nur Teile der Buttons falsch gezeichnet werden.

Um das Problem gezielt nachzuvollziehen habe ich ein kleines Sample gebaut. Man kann durch zwei Schalter den CScrollView gezielt nach oben oder unten Rollen. Beim Rollen nach unten und bei bestimmten Fenstergrößen tritt dann der Fehler auf. Ich habe das Main-Window entsprechend beim Start in der Größe angepasst.

Das Problem liegt in einer Implementierung von WM_PRINTCLIENT in CScrollView (CScrollView::OnPrintClient), die ein Double-Buffering verwendet, dass entweder falsch ist oder sich eben mit der Standardimplementierung eines Dialoges beißt. Auf den ersten und zweiten Blick konnte ich in der Implementierung selbst keinen Fehler sehen. Deshalb vermute ich, dass sich dieses Double-Buffering mit dem auch vorhandenen Double-Buffering in den Standardimplementierungen der Dialogklasse beißt bzw. nicht korrekt berücksichtigt, dass auch Child-Windows neu gezeichnet werden müssen.

Die Lösung ist entsprechend einfach:

  • Man fügt einfach einen Handler für WM_PRINTCLIENT in seiner von CFormView abgeleiteten Klasse ein.
  • Dieser Handler ruft dann nicht die Implementierung der Basisklasse CFormView auf, sondern die Implementierung in CView (CView::OnPrintClient).
...
ON_MESSAGE(WM_PRINTCLIENT,&CScrollDialogMFCView::OnPrintClient)
...

LRESULT CScrollDialogMFCView::OnPrintClient( WPARAM wp, LPARAM lp )
{
  // Bypass the CScrollView::OnPrintClient implementation
  return CView::OnPrintClient(wp,lp);
}

Dieser Fehler ist in keiner der vorhergehenden MFC Versionen vorhanden (auch nicht in MFCNext), weil einfach kein entsprechender Handler vorhanden war..

Es stellt sich wohl bei einigen jetzt die Frage warum dieser Handler eingebaut wurde. Auch die Antwort ist einfach:
Seit Windows Vista wird stark von AnimateWindow Gebrauch gemacht und auch DWM intern scheint des öfteren WM_PRINT/WM_PRINTCLIENT zu verwenden. Entsprechend haben fast alle Klassen in der MFC entsprechende Handler ergänzt bekommen.

Das Sample kann man hier herunterladen: ScrollDialogMFC – VS-2010.
Ich habe in der stdafx.h einen define FIX_CSCROLLVIEW_PROBLEM eingebaut mit dem man den Fix einfach aktivieren und deaktivieren kann.

Eventlog Einträge mit der Ereigniskennung 675 im Sicherheit Ereignisprotokoll

Auf meinem Windows Server 2003 R2 haben sich in der letzten Zeit Fehlereinträge im Eventlog für die Sicherheit angehäuft. Und das bis zu 200 Einträge und mehr täglich.

Bei der Analyse stieß ich hauptsächlich auf die Ereigniskennung 675 mit dem Fehlercode 0x19. Meistens traten diese Eventlog Einträge im Viererpack auf, immer wenn ein Benutzer sich mit seinem PC im Netz angemeldet hat. Jeweils erschienen dann Einträge für den PC und den Benutzer, wie die nachfolgenden Beispiele beiden Beispiele aus dem Ereignisprotokoll meines Servers zeigen:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:33
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: COMPUTER$
  Benutzerkennung: DOMAIN\COMPUTER$
  Dienstname: krbtgt/domain.loc
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

sowie:

Ereignistyp: Fehlerüberw.
Ereignisquelle: Security
Ereigniskategorie: Kontoanmeldung
Ereigniskennung: 675
Datum: 21.04.2010
Zeit: 10:48:52
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SERVER
Beschreibung:
Fehlgeschlagene Vorbestätigung:
  Benutzername: Martin
  Benutzerkennung: DOMAIN\Martin
  Dienstname: krbtgt/DOMAIN
  Vorauthentifizierungstyp: 0x0
  Fehlercode: 0x19
  Clientadresse: 192.168.16.150

Nach einiger Recherche kam ich dahinter, dass dies nur Arbeitsplätze betraf, die Windows Vista oder Windows 7 einsetzten. Rechner mit Windows XP oder Windows 2003 Server tauchten hier nie auf.

Ein wenig weiteres Forschen brachte mich dann auf die Ursache:

Diese Event Id wird ausgegeben wenn, der Domänencontroller den Kerberos-Authentifizierungsversuch eines Rechners nicht versteht. Das nur Windows Vista und Windows 7 Rechner als Verursacher auftauchen liegt daran, dass mit Windows Vista AES (Advanced Encryption Standard) als Verschlüsselungsverfahren von den Clients bevorzugt wird.
Leider kennt aber der Windows 2003 Domänen-Controller dieses Verfahren noch nicht. Weil es aber einen Fallback auf das RC4-HMAC Verfahren gibt merkt der Anwender nichts davon.

Windows Systeme unterstützen die folgenden Verschlüsselungsverfahren für Kerberos:

  • DES-CBC-CRC (Registrycode 0x1)
  • DES-CBC-MD5 (Registrycode 0x3)
  • RC4-HMAC (Registrycode 0x17)
  • AES (Registrycode 0x12) Wird seit Windows Server 2008 unterstützt (d.h. auch Vista und Windows 7)

Die Standard Preauthentifizierung erfolgt bei Windows 2000, Windows Server 2003, Windows XP immer RC4-HMAC.

Die Lösung ist ein kleiner Workaround in dem man einfach dem Vista oder Windows 7 Rechner mitteilt er soll doch einfach auch die RC4-HMAC Verschlüsselung wählen. Das verhindert dann die Nutzung von AES  und die Fehler sind weg, die durch den vergeblichen AES Anmeldeversuch entstehen.
Das erreicht man in dem man den Code 0x17 (siehe Aufzählung oben) für den DefaultEncryptionType einträgt. Nachfolgend der entsprechende Auszug aus der REG-Datei, die ich auf die Clients verteilt habe.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"DefaultEncryptionType"=dword:00000017

Oder in anderen Worten gesagt:

  • Man startet Regedit an den betroffenen Clients
  • Man wählt den Ast HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters
  • Dort erzeugt man einen DWORD Wert mit Namen DefaultEncryptionType
  • In diesen Wert setzt man 0x17 (bzw. 23 dezimal) ein

Nun ist Ruhe mit diesem Fehler 🙂

Weitere Links zum Thema Kerberos hier:
http://technet.microsoft.com/en-us/library/cc738673(WS.10).aspx
http://tools.ietf.org/html/rfc4757

Mein „Baby“ ist nun „Kompatibel mit Windows 7“

Das meine Software auf allem läuft was Windows XP und später heißt war mir schon lange klar 😉 aber ein offizielles „Kompatibel für…“ ist ja schon noch was anderes.
Jetzt habe ich die kostenlose Zertifizierung für die Windows 7 Kompatibilität hinter mich gebracht.
In Klartext ganz offiziell: AG-VIP SQL in der Version 1.20.008 ist kompatibel mit Windows 7 ❗

Verglichen mit der Vista Zertifizierung, die wir bei einem 3rd Party Unternehmen (VeriTest) durchgeführt haben, muss ich sagen: Windows 7 kompatibel zu werden ist nicht schwer
Es war wirklich kein großer Aufwand!

Wer sich die Spezifikationen durchgelesen hat wird sehen, dass sich gegenüber der Vista Zertifizierung kaum was geändert hat. Wer also seine Software bereits Vista kompatibel hat, kann gleich einen Durchstart machen und es für Windows 7 auch probieren. Und das schöne: Es kostet nichts!
Ich habe es nicht versucht, aber ich vermute mal, dass genau die Version die ich für Vista eingereicht habe auch durch die Windows 7 Zertifizierung gekommen wäre.

Noch ein paar Anmerkungen:

  • Ich kann jeden ermutigen, den Test zu machen, wenn man sowieso schon ein Code Signing Zertifikat und einen 64bit Rechner zur Verfügung hat. Wenn man auf dem man 64bit Windows 7 virtualisieren kann ist die Zertifizierung wirklich einfach. Ich habe VMWare benutzt und das ist einfach ein super Werkzeug für so etwas.
  • Wie bei vielen Zertifizierungen wird viel zu viel Gewicht auf Installation und Deinstallation gelegt. Das war bei der Vista Zertifizierung auch schon so.
  • Bei der Vista Zertifizierung war noch klar, wie und wo man Waiver (Freistellungen) bekommt, z.B. für Komponenten von Drittherstellern, die Ihre DLLs nicht signieren. Dazu gehört ja auch Microsoft mit den DLLs der MFC 😉
    In diesem Zertifizierungsprozess, erfährt man, dass man sie evtl. benötigt, aber nicht wo man sie bekommt…
  • Manche in meinen Augen wertvolle Tests in der Vista Zertifizierung, wie zum Beispiel, die korrekte Behandlung von Crashes, scheinen vollkommen entfallenzu sein.
  • Der Test bei dem 3rd Party Unternehmen war weitaus tiefer als das was man bei dem Selbsttest macht. Jetzt genügt ja die Software zu starten und wieder zu beenden. Bei den Tests zu Vista sind wir beim ersten mal durchgefallen, weil hier ein Bug in der MFC mit dem Application Verifier gefunden wurde, der uns beim Testen nicht aufgefallen war  (Siehe 1, 2, 3) 
    Ich empfinde den Selbsttest als zu schwach um dann ein Windows 7 kompatibel Logo zu bekommen.
  • Man muss versichern, dass man keine Spyware zertifiziert oder andere böse Software erzeugt… gelinde gesagt ein Scherz. Bei einem 3rd Party Tester würde solche Spyware (hoffentlich) nicht durchkommen. Das hoffe ich doch wirklich mal! Jetzt muss man nur einen Haken setzen, und sich selbst bestätigen, dass man es nicht tut, obwohl man es evtl. doch tut… 😉
    Das mindert den Wert dieses Logos ungemein.
  • Wenn man früher Geld investierte für eine Zertifizierung, hieß das nicht, dass man deshalb bessere Software produziert. Aber 1000$ waren dennoch eine Schwelle über die nicht jeder Hanswurst mit seiner Mickey-Maus-Software gegangen ist.
    Jetzt bleibt als Schwelle nur noch der Kauf eines Code-Signing Zertifikates bei VeriSign und so was kostet ca. 500$ im Jahr.
  • Ich vermisse schon lange das Verbot anderer Techniken, zum Beispiel ein Verbot von Systemweiten Hooks, wenn man Windows X kompatibel sein will. Wenn dann sollte so etwas auch nur mit einem Waiver und klarer Begründung erlaubt werden.
    Nicht wenige dieser mies programmierten Hooks sorgen für Instabilität, unnützes Aufblähen von Prozessen und manchmal auch miese Performance.

Als Fazit bleibt für mich die Frage:
Was nützt ein Logo, dass man zu leicht bekommen kann?

Es bleibt eine Marketing-Aktion und genauso wurde die Vista und jetzt auch die Windows 7 Zertifizierung auch bei uns in der Firma eingestuft. Technischen Nutzen hat das ganze nicht wirklich.

Nett: Windows 7 und sein GodMode ;)

Alleine der Name macht einen ja schon neugierig…

Was verbirgt sich dahinter?
Nichts anderes als eine Explorer Ansicht, die alles aus den Systemsteuerungspanels in einer Liste anzeigt. Nett…

Wie macht man das?

  1. Man legt auf dem Desktop (oder sonst wo) ein neues Verzeichnis an.
  2. Dieses Verzeichnis benennt man dann um in GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
    Wobei der Name vor dem Punkt keine Rolle spielt. Es geht nur um die Extension und die GUID.
  3. Fertig! Das Symbol verändert sich dann auf das Symbol der Systemsteuerung.

Gefunden in: Understanding Windows 7’s ‚GodMode‘

Nachtrag 1: Das Ganze geht sogar unter Vista 32bit!
Nachtrag 2: Es gibt Meldungen, dass dieser Link auf dem Desktop eines Vista 64bit Systems den Explorer zum Absturz bringt!
Evtl. sollte man den Ordner testweise in diesem Fall erstmal in einem Unterordner anlegen.
Nachtrag 3: Auch Kay Giza berichtete ausführlich über diesen Modus, ich hatte dies allerdings übersehen.
http://www.giza-blog.de/Windows7VistaErweiterteSystemsteuerungAktivierenED7BA4708E54465E825C99712043E01C.aspx

Installation älterer Software auf Windows-Vista oder Windows 7

Jetzt wo sich Windows 7 langsam immer weiter verbreitet werden manche Benutzer feststellen, dass Windows 7 so viel anders als Vista nicht ist.
Insbesondere wenn es um Probleme mit älterer Software geht.
Ja es gibt den XP-Modus unter Windows 7, aber manchmal geht es eben doch mit ein paar Tricks und man die Software richtig installieren ohne XP-Mode-Overhead.

Ich habe die Erfahrung gemacht, dass die Virtualisierung durch UAC einiges leistet und dafür sorgt das einiges an Software unter Vista und Windows 7 laufen kann.
Ansonsten kann man manchmal nachhelfen, wenn man dem Programmen auf die entsprechenden Ordner in Program Files und HKLM in der Registry die Rechte für einen normalen Benutzer auf Vollzugriff setzt.
Ich mache dies nur für die Teiläste dieses Programmes, insofern kein allzu großes Sicherheitsrisiko, aber es wirkt oft Wunder. Unter XP habe ich damit ältere Siedler Versionen zum Laufen gebracht ohne das man Administrator sein musste 😉

Leider gibt es aber auch Fälle in denen die Software schon die Installation verweigert. Auch hier kann man manchmal auf einem XP Rechner installieren und dann die Software kopieren.
Aber es gibt auch hier Tricks, wenn einfach nur die Versionnummer falsch geprüft wird (was leider ziemlich oft passiert).

In meinem Beispiel war es RC-WinTrans, dass die Installation schon unter Vista verweigert hat.
Ein Blick mit Orcas in die MSI Datei zeugt eine falsche Versionsprüfung:

Installation unter Vista Windows 7-1

Unschwer zu erkennen, dass hier explizit auf die unterstützten Versionen geprüft wird und die Version 6.x für Vista und Windows 7 eben nicht durch diesen Test abgedeckt sind.

Mit Orcas ist das schnell geändert:

Installation unter Vista Windows 7-2

Und siehe da. Nicht nur die Installation läuft einfach und glatt.
Die ganze Software arbeitet perfekt unter Vista und Windows 7.

BTW: Wenn man eine EXE hat, die die Installation ausführt, dann kann man versuchen über den Karteireiter Eigenschaften der EXE Datei, den Kompatibilitätsmodus auf Windows XP SP2/SP3 zu setzen. Auch dann gelingt einem oft die Installation selbst wenn eine falsche Versionsnummer intern im Setup geprüft wird.

Windows Integrity Control: Schreibzugriff auf eine Named Pipe eines Services über anonymen Zugriff auf Vista, Windows 2008 Server und Windows 7

Mein Problem war ein Service, der eine Pipe als Interface zur Verfügung stellt, auf die von beliebigen PCs zugegriffen werden soll. Insbesondere eben auch von PCs außerhalb der Domäne in der der Service läuft der die Named Pipe zur Verfügung stellt. Die Clients melden sich über VPN an dem entsprechenden Server an, gehören aber eben selbst nicht zur Domäne.

Von einem Rechner, der nicht in der Domäne des Rechners liegt, auf eine Pipe eines Rechners in einer Domäne zuzugreifen war schon immer mit extra Vorkehrungen verbunden. Der Code für den anonymen Zugriff auf eine Pipe finden wir als KB Artikel http://support.microsoft.com/kb/813414/en-us. Über die Qualität dieses Beispiels möchte ich mich hier allerdings nicht auslassen.

Dieses Sample ist nett für alle die XP und Windows 2003 Server nutzen. Und interessanter Weise funktioniert es auch auf Windows Vista, Windows 7 oder Windows Server 2008. Aber nur weil dieses Beispiel die Pipe nur lesend benutzt.

Dieses Programm berücksichtigt nicht die neuen Sicherheitsfunktionen von Vista, Windows 7 oder Windows Server 2008. Es klappt genau dann nicht, wenn der Server eben auf einem Vista, Windows 7, oder Server 2008 läuft UND die Pipe für Lesen und Schreiben geöffnet wird.  ERROR_ACCESS_DENIED (5) ist das was der Client dann bekommt, wenn die Pipe lesend und schreibend geöffnet werden soll.

Was ist das Problem ❓

Das Problem liegt in einem Sicherheitsmechanismus, der sogenannten Windows Integrity.
Ich rate jedem die Literatur der nachfolgenden beiden Links:

 

Kurzbeschreibung:
Prozessen oder auch anderen Systemobjekten wird ein Inegrity-Level zugeordnet.
Greift nun ein Prozess auf ein Systemobjekt zu, dann werden nicht nur die allgemeinen Rechte geprüft (z.B. Rechte für Anonymen Zugriff, oder die entsprechenden Gruppenrechte), sondern auch der Integrity Level dieses Prozesses wird mit dem der Ressource verglichen.
Liegt nun der Integrity Level des Clients niedriger als der Intergrity Level des Objektes, dann greift eine neue Policy, die dann festlegt was passiert. In den meisten Fällen bedeutet dies, dass der Lesezugriff zugelassen wird, aber der Schreibzugriff untersagt wird.

Übrigens passiert das gleiche, wenn man ein Addin für den IE8 auf Vista (und später hat). Der IE8 läuft im geschützten Modus und damit im Integrity Level Low. Normale Programme laufen im Integrity Level Medium.
Möchte nun das IE8 Addin eine Pipe oder einen Shared Memory Block eines Services oder eines „normalen“ anderen Programmes, schreibend öffnen, dann passiert das gleiche. Der Zugriff wird reduziert auf nur lesen.
Und dieses Thema wird hauptsächlich in der Doku und im Netz diskutiert (und zum Teil, gelöst).

Ich will das jetzt hier nicht über die Maßen ausdehnen. Ich kann nur anraten, die entsprechenden Artikel wirklich einmal zu lesen.

Jetzt zurück zu dem was NICHT in diesen entsprechenden Artikeln und Forumbeiträgen steht.

1. Anonymen Zugriff wird automatisch der Integrity Level Untrusted zugewiesen. Die Doku zeigt in dem Beispiel nur die Vorgehensweise für den Integrity Level low.
Mein Fehler war es, die ganze Zeit SECURITY_MANDATORY_LOW_RID zu verwenden. Aber ich sagte es schon: Der  Anonyme Zugriff erfolgt im Integrity Level Untrusted.

2. Ich arbeite mit SDDL String und auch dort in den Headern ist Low das niedrigste für das es im Netz und auch in der Doku (http://msdn.microsoft.com/en-us/library/bb625963.aspx) findet. Dort steht ziemlich weit unten ein Beispiel, um ein Objekt einem „Low“-Integrity-Prozess zugänglich zu machen. Und dort finden wir folgende SDDL Definition:

#define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"

3. Anonymer Zugriff ist also Integrity Level Untrusted (ich weiß ich wiederhole mich).
Und nun wird es spaßig. Es gibt auch gar keinen SDDL Sid für untrusted, es gibt nur die folgenden Definitionen in den Headern:

// Integrity Labels
#define SDDL_ML_LOW                         TEXT("LW")
#define SDDL_ML_MEDIUM                      TEXT("ME")
#define SDDL_ML_MEDIUM_PLUS                 TEXT("MP")
#define SDDL_ML_HIGH                        TEXT("HI")
#define SDDL_ML_SYSTEM                      TEXT("SI")

Alles das hat mich in die Irre geführt und 2 Tage Arbeit gekostet.

Als mir klar war, dass ich eine Regel für den Untrusted Intergity Level benötige, war die Lösung gefunden.
Bauen wir uns einen eigenen SID! Aus der Doku können wir die entsprechenden RIDs finden und uns nun folgenden SID konstruieren: „S-1-16-0“.
Und das bringt uns zu dem SDDL String für den Level untrusted:

#define UNTRUSTED_INTEGRITY_SDDL_SACL _T("S:(ML;;NW;;;S-1-16-0)")

Ich habe das oben beschriebene Sample etwas modifiziert, dass man genau dieses Problem des anonymen Zugriffs auf eine Pipe testen kann. Das Beispiel kann man hier herunterladen.
Ich habe das Sample dazu etwas umgebaut:

  • so dass lesender und schreibender Zugriff auch benutzt wird.
  • dass SDDL verwendet wird, was den Code extrem simplifiziert.
  • dass zumindest etwas an dem ekligem Code lesbarer wurde.
  • dass ein paar Bugs raus sind.

Ich bitte dennoch dies nur als Sample zu betrachten und nicht als Beispiel Software, die meinem Anspruch an C/C++ Code genügt 🙂

PS: Eine entsprechende Diskussion über das Problem findet sich in nntp://microsoft.public.de.vc
http://groups.google.de/group/microsoft.public.de.vc/browse_thread/thread/3be20505999b8aab
Danke noch mal explizit an den Regular Andreas Heyer für seinen wertvollen Diskussionsbeitrag.

Nach Windows 7 Upgrade einige GB an Plattenplatz freigeben

Nachdem ich vor einigen Tagen ein Update auf meinen Vista Rechner auf Windows 7  durchgeführt habe, sind mir zwei versteckte Ordner im Rootverzeichnis auf meiner Festplatte aufgefallen, die nicht klein sind.

Durch eingeschränkte Rechte hat man normalerweise keinen Zugriff, aber wenn man eine elevated Session mit dem Explorer startet kann man herausbekommen was sie beinhalten:

$WINDOWS.~Q    2200 MB (2.364.075.683 Bytes)
$INPLACE.~TR    471 MB (  494.284.806 Bytes)

Die Dateien in diesem Ordner schienen auf den ersten Blick irgendwas mit dem Update zu tun zu haben.

  • Der erste Schritt: Mal in der Systemsteuerung nachsehen ob man dort etwas deinstallieren kann. Nada.
  • Zweiter Blick: Starten der Datenrägerbereinigung. Auch nichts auffälliges.
  • Dritter Versuch: Starten der Datenträgerbereinigung als Administrator. Bingo ❗

Siehe da:

Datenträgerbereinigung

Zwei Dateigruppen finden sich:
Beim Window-Upgrade verworfene Dateien – und –
Protokolldateien für Windows-Upgrades

Anhaken und Schwupps sind 3GB mehr Plattenplatz da…

Upgrade meines privaten Desktop PCs auf Windows 7

Meinen neuen Samsung Laptop, den ich vor ca. 2 Monaten gekauft habe, wurde gleich platt gemacht und mit Windows  7 versehen.
Ich musste nicht einen Treiber nachinstallieren. Alles hat Windows 7 selber erkannt und es lief alles weitaus glatter als erwartet.

Heute habe ich den Mut gefasst und meinen privaten Desktop PC von Vista Ultimate 32bit auf Windows 7 Ultimate upzugraden. Kurz zuvor hatte ich mit meinem schönen Acronis Home 2010 noch ein Backup gemacht. Ohne würde ich es nicht wagen.
Und zuvor habe ich natürlich mit dem Upgrade Advisor geprüft ob es irgendwelche Probleme eben wird, dem war nicht so.
Zu einer Neuinstallation fehlt mir einfach die Muße, bis alles wieder läuft würden Stunden vergehen. Also wage ich das Upgrade!

Kurz vor dem Länderspiel um 17:00 habe ich das Setup gestartet, um ca. 21:45 war das Upgrade durch.

Gleich zu Anfang beschwerte sich das Setup über drei Programme:

  • Adobe Reader 7 (der definitiv nicht auf meiner Maschine war)
  • iTunes (mit dem ich die Musik für meinen IPod verwalte)
  • VMWare (mein ultimatives Testtool)
  • Cannon-EasyLayout Print (gehört zu meinem Drucker)

Windows 7 Update hatte mir empfohlen die Programme zu deinstallieren. Ich habe die Hinweise einfach ignoriert, denn alle drei Programm sind für mich nicht lebenswichtig und lassen sich nachinstallieren.

Da ich einige sehr große Dateien auf dem Rechner habe (ISO-Images etc.) hatte ich manchmal zwischendrin ganz schön Bammel ob das Setup durchläuft. Zwischendrin blieb die Prozentzahl der Fortschrittanzeige ziemlich oft und lange auf einem Wert stehen (10 Minuten lang).

Irgendwann war es so weit und ich konnte mich anmelden und … Spannung ❓
Keine Probleme. Alles läuft auf Anhieb ❗
Alle Treiber, alle Geräte inklusive WLAN, WebCam, SD-Kartenleser, Videokarte usw. sind sofort betriebsbereit.
Gleiches gilt für alle Software, Acronis 2010 Home, ESET Antivirus, Office etc.

Erster Eindruck:

  • Windows 7 läuft wirklich flüssiger und flinker. Eindeutig auch weniger Festplattenaktivität zu hören.
  • Grundsätzlicher Hauptspeicher Bedarf etwa 8% weniger als unter Vista zuvor. Windows 7 will 44% meines Speichers gleich nach dem Start, Vista wollte 52%.
  • Das Upgrade von Vista auf Windows 7 ist vollkommen schmerzfrei. Alles wurde 1a übernommen.
  • Sich mit dem Windows 7 Heimnetzwerk anzufreunden macht Spaß!

Ich kann ein Update nur empfehlen ❗

Da installiert man 64bit und schon fängt man an sich zu ärgern…

Ich hatte es befürchtet. Bisher bin ich mit allen meinen privaten PCs bei 32bit Betriebssystemen geblieben.

Nun habe ich Windows 7 und habe mich mutig für meinen netten Samsung Laptop für ein 64bit OS entschieden. Dann kann ich meine 4GB Speicher wenigstens auch komplett nutzen.

Und jetzt fange ich schon an mich zu ärgern, denn ich benutze gerne Groove 2007 (die Ordnersynchronisation), weil es einfach praktisch ist. Aber was sehen meine Augen beim einrichten des Grove Kontos auf dem Rechner:

Groove-Dateifreigabe-Arbeitsbereiche werden in 64-Bit-Betriebssystemen nicht unterstützt.

Nicht zu fassen… Überall wird ein 64bit Hype betrieben und viele Werkzeuge funktionieren darauf nicht.
Und schon fange ich mich zu ärgern 😐 Manchmal sollte man sich vorher klug machen bei dem was man will.

Microsoft SQL Server Management Studio Express auf Vista schlägt fehl. Fehler 29506

Fehlermeldung 29506Ich wollte mir das Microsoft SQL Server Management Studio Express auf Vista installieren. Aber während der Installation erhielt ich die folgende Fehlermeldung:

Bei der Installation dieses Pakets ist ein unerwarteter Fehler aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem vor. Der Fehlercode ist 29506.

Und nun? Man sollte doch annehmen, dass eine MSI-Datei sich installieren lässt und auch im Admin-Modus installiert wird. Pustekuchen.

Es geht doch, mit einem Trick:

Man starte eine Console im Admin-Modus: Rechtsklick auf die Verknüpfung und Als Administrator ausführen wählen. Dann von dort die entsprechende SQLServer2005_SSMSEE.msi aufrufen. Dann läuft das Setup ohne Fehler durch.

Langsam habe ich das Gefühl, dass dieses Verfahren zur Installation unter Vista grundsätzlich zu empfehlen ist. Leider kann man MSI-Pakete nicht direkt über ein Kontextmenü im Admin-Modus installieren.
Das wäre was für Vista SP1 😉

Nachtrag 22.08.2009:
Das Problem betrifft auch die Installation unter Windows Server 2008 als auch Windows 7, sofern UAC eingeschaltet ist. Das MSI Paket muss in jedem Fall als Admin (elevated) gestartet werden.