Martin's Blog

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.

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:

• Windows Integrity Mechanism Design
  http://msdn.microsoft.com/en-us/library/bb625963.aspx
• Windows Vista for Developers – Part 4
  http://weblogs.asp.net/kennykerr/archive/2006/09/29/windows-vista-for-developers-_1320_-part-4-_1320_-user-account-control.aspx

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.

Am 17. Januar habe ich den folgenden Artikel geschrieben: DrawText unter Vista gegenüber XP um bis zu Faktor 50 langsamer!

Ich möchte Euch die Auflösung des Problems nicht vorenthalten.

Eigentlich ist es keine Lösung sondern nur der Fakt, dass auch XP unter gleichen Bedingungen genauso lahm ist wie Vista.
Es liegt an den erweiterten Spracheinstellungen, die unter XP optional sind aber eben nicht mehr unter Vista. Dort sind die immer mit installiert.

So sieht das ganze bei einer normalen XP Installation aus, mit der entsprechenden Performance:

Man kann sehen, dass die zwei unteren Checkboxen aus sind. Wenn man diese nun einschaltet und die entsprechenden Module nachinstalliert werden, dann erlebt man unter XP nach einem Neustart die selben Geschwindigkeitseinbruch wie unter Vista:

Mein Testprogramm läuft fast 50mal langsamer als bei der Standardinstallation und damit genauso schnell/lahm wie unter Vista. Nimmt man die zwei Checks wieder heraus, dann hat man den alten gewohnten Speed.

Wenn man unter Vista in den entsprechenden Dialog der Systemeinstellung sieht, kann man auch sehen, dass man hier nichts mehr beschleunigen kann durch eine eventuelle Deinstallation, denn offensichtlich gehören diese Bestandteile bei Vista zum Inventar:

So und damit ist auch diese Supportanfrage bei Microsoft “ungelöst”, aber zumindest “erklärt” geschlossen.

Ich frage mich dennoch warum eine solche EInstellung solche Auswirkungen haben muss. Letzten Endes sind das auch nur Fonts mit denen umgegangen werden muss. Ich finde diesen extremen Unterschied auffällig, allerdings wird sich vermutlich nichts daran ändern…

Ich wünsche allen Lesern einen schönen Juli und verziehe mich jetzt erstmal für die nächsten 2 1/2 Wochen ohne Laptop und PC an die Nordsee, zum Radfahren, Baden und Drachen steigen lassen…

Manchmal kann man den Standby Mode wirklich nicht gebrauchen. Besonders, wenn man ein Programm hat, dass evtl. viel im Hintergrund mit einer Datenbankverbindung macht.

Wie macht man es unter Windows Vista richtig, denn BROADCAST_QUERY_DENY bei einem PBT_APMQUERYSUSPEND oder PBT_APMQUERYSUSPENDFAILED zurückzugeben funktioniert nicht.
Man muss SetThreadExecutionState verwenden!

Äußerst dumm nur, dass man dies auch wirklich für Windows Vista und Windows 7 berücksichtigen muss. Ich hatte natürlich für Windows 2000 und XP entsprechenden Code vorgesehen, die den Standby verhindern, aber wie schon erwähnt, das geht eben unter Vista nicht mehr.
Es gibt Inkompatibilitäten zwischen des OSen, die man wirklich explizit behandeln muss. Es lohnt sich ein Blick in die Dokus, den ich selber oft genug nicht mache…

// Every 30 secs we disallow the standby and hibernate!
// We have to use ES_AWAYMODE_REQUIRED on Vista and Windows Server 2008
// If we allow standby and hibernation we get problems with the DB connection.
DWORD dwAwaymodeRequired = 0;
OSVERSIONINFO os;
::ZeroMemory(&os,sizeof(os));
os.dwOSVersionInfoSize = sizeof(os);
if (::GetVersionEx(&os) && os.dwMajorVersion>=6)
    dwAwaymodeRequired = ES_AWAYMODE_REQUIRED;
VERIFY(::SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED |
	dwAwaymodeRequired));

Das damit auch die Funktion CListCtrl::GetSubItemRect aus der MFC betroffen ist, ist dann auch  klar.
Manche Sachen ärgern einen einfach. Vor allem wenn man nichts am Code ändert und doch falsches Verhalten erntet.

Wieder mal ist die Vista UI eigentümlich ungereimt, in diesem Fall bei einem List View.

Folgendes ist gegeben:

• Ein List View (SysListView32) in einem Dialog oder anderen Fenster
• Der List View hat den Stil LVS_REPORT
• Der List View hat hat mehr als eine Spalte.
• Dem List View wurde eine Imagelist zugewiesen.

Führt man nun auf Windows XP LVM_GETSUBITEMRECT /CListCtrl::GetSubItemRect mit LVIR_ICON aus, dann erhält man immer ein Rectangle zurück mit der entsprechenden Weite der Imagelist Symbole. Das Verhalten ist:

• vollkommen unabhängig ob ein Manifest für COMCTL32.DLL Version 6.0 vorhanden ist oder nicht
•  es ist auch unabhängig ob LVS_EX_SUBITEMIMAGES gesetzt ist oder nicht.

Macht man das ganze unter Vista, dann liefert LVM_GETSUBITEMRECT /CListCtrl::GetSubbItemRect ein RECT / CRect mit der Weite der Symbole immer dann wenn:

• kein Manifest für COMCTL32.DLL Version 6.0 vorhanden ist
• oder LVS_EX_SUBITEMIMAGES gesetzt ist

Das heißt in dem Fall

• ein Manifest für COMCTL32.DLL Version 6.0 ist
• und LVS_EX_SUBITEMIMAGES ist nicht gesetzt .

erhält  man ein Rectangle mit der Weite 0 (Null)

Anmerkung:
 Man kann sich natürlich streiten was nun richtig ist. Wenn LVS_EX_SUBITEMIMAGES nicht gesetzt ist, dann macht LVIR_ICON zugegebenermaßen wenig Sinn. Aber es leuchtet irgendwie nicht ein, dass ohne Manifest und ohne LVS_EX_SUBITEMIMAGES, wieder ein Wert zurückgeliefert wird. Entweder ist die Weite von LVS_EX_SUBITEMIMAGES abhängig oder eben nicht.
Das Ganze ist in jedem Falle mal ungereimt und nicht kompatibel

Nachtrag 26.03.2009:
Das List-Control liefert für das Subitem 0 immer ein korrektes Rectangle für LVIR_ICON! Nur wenn wirklich ein Subitem (>0) abgefragt wird, tritt das Problem auf.

Ich hatte in einem unserer Release-Kandidaten ein massives Problem. In bestimmten nicht reproduzierbaren Situationen, blieb zeitgleich auf allen angeschlossenen Arbeitsstationen das Programm stehen. Und nun?

Der Deadlock, der auftrat war so fatal, dass ich nicht mal mehr über eine versteckte Funktion einen Speicherdump auslösen konnte. Dazu verwende intern üblicherweise eine reservierte Tastenkombination. Nur wenn keine Nachrichten mehr abgearbeitet werden, gibt es auch keine Funktionen, die man per Tastatur aufrufen kann.

Glücklicherweise wurde auf allen betroffen Rechner Windows Vista eingesetzt. Und die Lösung für diesen Fall ist unter Vista so einfach wie genial. Im Task-Manager unter Vista findet sich im Kontextmenü ein unauffälliger Menüpunkt: “Abbilddatei erzeugen”:

Jupp! Er macht genau was ich brauchte. Durch diesen netten Befehl wird im %TEMP% Verzeichnis des Benutzers ein voller Speicherdump erzeugt.

Ich musste von 6 Dumps genau 2 durchsehen, bis ich das Problem lokalisiert hatte.
Eine wirklich nette und nützliche Funktion des Taskmanagers.

Unter Windows XP kann man ähnliches machen nur ist es hier ungleich komplizierter, aber es geht auch mit dem mitgelieferten symbolischen Debugger NTSD und den folgenden Schritten:

• PID über den Task-Manager ermitteln (entsprechende Spalte einblenden lassen)
• NTSD starten mit der entsprechenden PID
  NTSD -p 4656
• Dump erzeugen:
  …
  0:001> .dump /f c:\temp\crash\full.dmp
  Creating c:\temp\crash\full.dmp – user full dump
  …
• Wird der Debugger mit Quit (q) verlassen wird auch der Prozess beendet.

Sorry for blogging in English. I know that I am breaking my own rules

Reasons for this article:
In the last years I found it more an more complicated to get bugs fixed in current software produced by Microsoft. My experience showed me, that the Microsoft product teams always look for new versions and new features and the Microsoft support teams and engineers don’t produce enough pressure that well known bugs get fixed in the currently used software products.

The reason why the Microsoft support rejected a request for a fix was very often that not enough customers are affected by the problem or bug. And this is often a problem for me and my company. We are just a small ISV so we can’t point to millions of affected users. And yes I know that hotfixes are expensive.
So usually we have to be flexible and have to find work arrounds.
But my feeling is that there would be enough impact and pressure for a hotfix, if it would be known to the public what problems exist and that there are others who have a request to get a special problem fixed.
Also a lot of programmers tend to avoid the creation of a support request, because the experience  shows: You put energy, time (and money) into a support request and the answers are in most cases: Will not get fixed, by design, and so on…

Another experience in the last years was, that even being an MVP doesn’t help to get anything fixed by Microsoft even if a lot of MVPs point out that there is a real need for a change or fix. 

So I just want to choose a new way, because there is no way to get votes of other people to a standard bug in a Microsoft product like it is possible on Microsoft Connect. But Connect is absolutely worthless if the product is already shipped!
I want to collect votes for this problem via my blog. I also informed the Microsoft support engineer who cares about the current incident.

If you agree and if you see a larger problem in this bug too, or if you have the feeling or knowledge that it has impact on your own software, than please write a comment to this blog article. Please leave your real email address or homepage URL. The email address will not be visible to the public, and I will forward it only to Microsoft if the poster agrees.

Description of the bug:

On January 17th, 2009 I reported a reproducible bug in Windows Vista in the article DrawText unter Vista gegenüber XP um bis zu Faktor 50 langsamer!  (The article is written in German, you find a description in English below in the next lines)

Fact:
Windows Vista and Window 7 are up to 50 times slower in the execution of a simple DrawText function with DT_CALCRECT set compared to Windows XP.
You can find the source code for a sample code (VS-2005 MFC project) that shows the bug here:  TestDrawText.zip. If you are just interested in the executable you can find it here TestDrawTextExe.zip.

And as far as I can see the overall performance of DrawText is affected.

My request:
If you find it important that this need a fix, or if you have the feeling or the knowledge, that you software might be effected. Please leave a comment here

Or feel free to vote on the bug I filed for Windows 7 on Microsoft Connect:
https://connect.microsoft.com/windows7/feedback/ViewFeedback.aspx?FeedbackID=401007

Thank you

Final Note (11.07.2009):
Read on here http://blog.m-ri.de/index.php/2009/07/11/ausloesung-drawtext-unter-vista-gegenueber-xp-um-bis-zu-faktor-50-langsamer/

Ja Ihr habt ganz richtig gelesen und ich irre mich nicht

Wir haben in einem unserer C++/MFC Programmen eine komplexe Anzeige von Reports, die alle unterschiedliche Zeilenhöhe haben und in einem speziellen Fenster angezeigt werden (eigene Entwicklung).
Nun stellten wir fest, dass das Rollen in diesem Programmteil auf Vista-Rechnern mit viel Nachlauf funktionierte und auch einige andere Operationen länger als gewohnt dauerten. Bei meinem Suchen, Profilen und Testen kam ich auf ein sehr lahmes Abarbeiten der Funktion DrawText  mit DT_CALCRECT.

Um das Problem zu isolieren schrieb ich ein kleines Testprogramm, das erstaunliches zu Tage brachte.
Hier die Ergebnisse von 4 verschiedenen Rechnern (Durchlauf von 100×100 DrawText Calls):

• Pentium Quad-Core Q8200 mit Vista: 48.111 msec
• Pentium Core2Duo T2310 mit Vista: 78.953 msec
• Pentium Dual Core 3,2Ghz mit XP: 1.516 msec
• Alter Pentium 3,0Ghz HT mit XP: 1.922 msec

Der Code ist teilweise um den Faktor 50 langsamer auf Windows-Vista im Vergleich zu Windows-XP

Wer Lust hat es selbst zu testen, der findet hier das Beispielprogramm im Sourcecode (VS-2005):  TestDrawText.zip
Wer das Programm als Exe möchte findet es hier: TestDrawTextExe.zip

Beschreibung:
Dieses Beispielprogramm führt gemäß einem angegebenen Zähler je 100mal DrawText mit DT_CALCRECT für einen längeren mehrzeiligen Text aus. Hierbei werden immer zufällige Textlängen verwendet. Der Algorithmus liefert jedoch immer die gleiche Zufallssequenz, damit der Test auch Vergleichbar bleibt.
Der Zufallsmechanismus wurde nur eingebaut, um für für meinen Fall realitätsnahe Daten zu liefern.

Anmerkung:
Eine entsprechende Supportanfrage bei Microsoft läuft
Was dabei herauskommt werde ich berichten…

Zuletzt angemerkt:
Windows 7 soll ja schneller sein als Windows Vista. Wer weiß? Ich habe es noch nicht getestet.
Vieleicht haben die nur diesen Bug gefixed und einen gigantischen Performanceschub erhalten … SCNR…

Nachtrag (11.07.2009): 
Die Auiflösung zu diesem Problem findet sich hier in diesem Artikel http://blog.m-ri.de/index.php/2009/07/11/ausloesung-drawtext-unter-vista-gegenueber-xp-um-bis-zu-faktor-50-langsamer/

In manchen Fällen kommt man um Environment Variablen nicht herum. Sie machen es auch einfach, globale Pfade für Linker, Präprozessor und auch für die Ausführung (PATH) zu setzen, oder eben auch EXEs und  DLLs zu steuern.

Solche Environment Variablen, bzw. INCLUDE und LIB Pfade zu setzen für das ganze System kann mühsam sein wenn man die Windows System UI nutzt. Der Aufruf ist umständlich und es erfolgt ein UAC-Prompt. Eine andere Variante wäre die Nutzung einer Reg-Datei. Dazu muss man aber wieder der UAC-Prompt über sich ergehen lassen.

Es geht viel einfacher, mit dem Helferlein SETX.EXE, das seit Vista nicht mehr nur im Windows Ressource Kit drin ist. Mit SETX kann man sich Ruckzuck ein kleines Batch-File schreiben, dass alle wichtigen Umgebungsvariablen für eine bestimmte Projektumgebung setzt.
Genial ist einfach, dass ab diesem Moment für jedes neu gestartete Programm diese Environment Variablen gelten. Natürlich inklusive der Visual Studio Umgebung.

In der Verbindung mit dem Aufruf von DEVENV /useenv kann man damit sehr schnell seinen Rechner auf eine komplett andere Projektumgebung einstellen. Und das ganze auch ohne UAC-Prompt Ja! Man glaubt es kaum. Es erfolgt ja auch nur Zugriff auf HKCU.

Anmerkung:Ich benutzt sehr gerne den Property-Manager nur ist es eben nur eine Lösung für alle Software, die aus dem Visual-Studio heraus gestartet wird, und es nützt gar nichts, wenn man die EXE/DLL selber mit unterschiedlichen Umgebungen testen will.

Und SETX ist auch noch wirklich extrem flexibel. Man kann nicht nur einfach eine Environment Variable setzen, wie man es mit SET kennt. Als Quelle können hier sogar Tetxdateien, Registryschlüssel genutzt werden. Und das Multitalent SETX kann sogar bei Angabe von Computername, Nutzername und Kennwort remote benutzt werden und damit auch die Systemweiten Parameter verändern.

Hier die Beschreibung von SETX /?

SetX hat drei verschiedene Ausführungsmethoden:

Syntax 1:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var Wert [/M]

Syntax 2:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var /K
         Registrierungspfad [/M]

Syntax 3:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]]
         /F Datei {var {/A x,y | /R x,y Zeichenfolge}[/M] | /X}
         [/D Trennzeichen]

Beschreibung:
  Erstellt oder bearbeitet Umgebungsvariablen in der Benutzer- oder
  Systemumgebung. Ermöglicht das Festlegen von Variablen, die auf
  Argumenten, Registrierungsschlüsseln oder Dateieingabe basieren.

Parameterliste:
  /S    System             Remotesystem für die Verbindungsherstellung.

  /U    [Domäne\]Benutzer  Bestimmt den Benutzerkontext, unter dem
                           der Befehl ausgeführt wird.

  /P    [Kennwort]         Bestimmt das Kennwort für den
                           Auslassung fordert zur Kennworteingabe auf.

  Variable                 Bestimmt die zu setzende Umgebungsvariable.

  Wert                     Bestimmt einen zu setzenden Wert
                           für die Umgebungsvariablen.

  /K    Registrierungspfad Bestimmt, dass die Variable auf Informationen
                           aus einem Registrierungsschlüssel basiert.
                           Gültiges Pfadformat:
                           Struktur\Schlüssel\…\Wert, z. B.
                           HKEY_LOCAL_MACHINE\System\CurrentControlSet\
                           Control\TimeZoneInformation\StandardName.

  /F    Datei              Bestimmt den Dateinamen der zu verwendenden
                           Textdatei.

  /A    x,y                Bestimmt die absoluten Dateikoordinaten
                           (Zeile X, Element Y) als Parameter, nach denen
                           innerhalb der Datei gesucht werden soll.

  /R    x,y Zeichenfolge   Bestimmt die relativen Dateikoordinaten im
                           Verhältnis zur “Zeichenfolge” als Suchparameter.

  /M                       Legt fest, dass die Variable in der
                           systemübergreifenden Umgebung
                           (HKEY_LOCAL_MACHINE) gesetzt werden. Der
                           Standardwert wird unter der Umgebung gesetzt
                           (HKEY_CURRENT_USER).

  /X                       Zeigt Dateiinhalte mit den x,y Koordinaten an.

  /D    Trennzeichen       Bestimmt zusätzliche Trennzeichen, wie z. B.
                           “,” oder “\”. Standardtrennzeichen sind
                           Leerzeichen, Tabulator, Wagenrücklauf und
                           Zeilenvorschub. Beliebige ASCII-Zeichen können
                           als zusätzliche Trennzeichen verwendet
                           werden. Die max. Anzahl an Trennzeichen,
                           einschließlich Standardtrennzeichen beträgt 15.

  /?                       Zeigt diese Hilfe an.

HINWEIS: 1) SETX schreibt Variablen in die übergeordnete Umgebung
            in der Registrierung.

         2) Auf einem lokalen System sind Variablen, die mit
            diesem Programm erstellt oder bearbeitet wurden,
            erst in zukünftigen und nicht in aktuellen
            cmd.exe Befehlszeilenfenstern verfügbar.

         3) Auf einem Remotesystem sind Variablen, die mit
            diesem Programm erstellt oder bearbeitet wurden, erst
            bei der nächsten Anmeldesitzung verfügbar.

         4) Gültige Registrierungsschlüssel-Datentypen:
            REG_DWORD, REG_EXPAND_SZ, REG_SZ, REG_MULTI_SZ

         5) Unterstützte Registrierungsstrukturen: HKEY_LOCAL_MACHINE
            HKEY_CURRENT_USER (HKCU).

         6) Bei Trennzeichen wird zwischen Groß-/Kleinschreibung
            unterschieden.

         7) REG_DWORD-Werte werden aus der Registrierung
            im Dezimalformat extrahiert.

Beispiele:
    SETX MACHINE COMPAQ
    SETX MACHINE “COMPAQ COMPUTER” /M
    SETX MYPATH “%PATH%”
    SETX MYPATH ~PATH~
    SETX /S System /U Benutzer /P Kennwort MACHINE COMPAQ
    SETX /S System /U Benutzer /P Kennwort ^%PATH^%
    SETX TZONE /K HKEY_LOCAL_MACHINE\System\CurrentControlSet\
         Control\TimeZoneInformation\StandardName
    SETX BUILD /K “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
         NT\CurrentVersion\CurrentBuildNumber” /M
    SETX /S System /U Benutzer /P Kennwort TZONE /K HKEY_LOCAL_MACHINE\
         System\CurrentControlSet\Control\TimeZoneInformation\
         StandardName
    SETX /S System /U Benutzer /P Kennwort BUILD /K
         “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
         CurrentVersion\CurrentBuildNumber” /M
    SETX /F ipconfig.out /X
    SETX IPADDR /F ipconfig.out /A 5,11
    SETX OCTET1 /F ipconfig.out /A 5,3 /D “#$*.”
    SETX IPGATEWAY /F ipconfig.out /R 0,7 Gateway
    SETX /S System /U Benutzer /P Kennwort /F c:\ipconfig.out /X

… und es war nicht etwa wieder Prof. Dr. Moriarty

Wenn man unter Vista einen Crashdump benötigt dann sucht man DRWTSN32.EXE unter Vista vergeblich. Für die Qualitätssicherung sind mir Minidumps immer extrem wichtig.

Es stellt sich die nette Frage: Wie kommt man von einem Kunden dann an einen informativen Minidump, wenn man keinen WER-Account hat, oder das Programm nicht signiert war, oder gar der WER Server diese Dumps nicht anfordert?

Unter Vista ist alles noch einfacher und schwieriger geworden. Vista speichert leider nicht grundsätzlich Minidumps, aber es legt für Crashs unter Problemberichte und Lösungen einen eigenen Eintrag an. Zu Crashs von WER registrierten Programme werden hier evtl. direkt Lösungen oder Updates angeboten. Und auch Crashdumps werden hier mit abgelegt, wenn sie erzeugt werden..

So ist es unter Vista aus:

1. Das WER System in Vista erzeugt normalerweise nur Minidumps für signierte Programme bzw. wenn der WER Server einen Crash abruft.
2. Um immer einen Minidump zu erhalten muss in der Registry der folgende Wert gesetzt werden:
   HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ (DWORD)  mit Namen ForceQueue  erzeugen und auf 1 setzen.
3. Dumps werden im Benutzerverzeichnis unter C:\Users\TheUserName\AppData\Local\Temp und hier C:\ProgramData\Microsoft\Windows\WER\ReportQueue abgelegt und sind meistens gepackt. Sie erhalten die Endung *.mdmp.
4. Der Zugriff kann ganz einfach erfolgen mit Systemsteuerung -> System und Wartung -> Problemberichte und Lösungen -> Probleme anzeigen und überprüfen
5. Dort findet man das entsprechende Programm und die dazugehörigen entsprechenden Crashs.
6. Weitere Infos einfach über Details anzeigen lassen.
7. Wenn es einen Dump gibt, dann findet man hier wieder einen Eintrag Temporäre Kopie dieser Dateien anzeigen
8. Damit lässt sich der Explorer öffnen und man erhält Zugriff auf die gespeicherten Daten.
9. Diese kann man sich nun als Entwickler zusenden lassen.

Siehe auch:

• Andere Möglichkeiten werden auch in diesem KB-Artikel beschrieben: http://support.microsoft.com/kb/931673/en-us.
• Alle Einstellungen des Vista WER Systems sind hier beschrieben:
  http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx