Manifest – Seite 2 – Martins Blog

Manifest-Hölle „…MSVCR80.dll nicht gefunden…“

Mir ist wieder einmal ein Projekt untergekommen, das in der Debug Version nicht starten wollte. Ursache diese Fehlermeldung:
„Die Anwendung konnte nicht gestartet werden, weil MSVCR80.dll nicht gefunden wurde. Neuinstallation der Anwendung könnte das Problem beheben.“

Der Grund für diesen Fehler war in diesem Fall ein Manifest, dass selbst geschrieben wurde und nicht durch den Manifest Compiler erzeugt wurde.

Der Reihe nach:

Es wurde ein Projekt gebaut, das eine externe Library benutzte
Diese externe Library wurde mit dem selben Compiler erzeugt. Sowohl als Debug, als auch als auch Release Version. (ZLib)
Alle Projekte verwenden dynamische Bindung an die CRT.
Der Entwickler machte nun aber einen kleinen Fehler. Im Debug Build instruierte er den Linker so, dass die Release Version der Library verwendet wurde. BTW: Ein Grund mehr immer #pragma comment(lib,…) zu verwenden, dann kann man in den Projekteinstellungen keinen Mist machen.
Wie ich schon erwähnte wurde nun das Manifest mit der Hand erzeugt um die entsprechenden Abhänigkeiten und auch das Trustinfo Manifest korrekt zusammenzubauen, bzw. weil nicht mit MT.EXE aus dem Vista SDK verwendet wurde (siehe mein Blog).
Die Release CRT wurde natürlich nicht mit angegeben (obwohl verwendet), aber dessen war sich natürlich keiner im Team bewusst.

Nun kam es zu dem Effekt, dass dieses Projekt im Debug Modus nicht starten wollte, weil die MSVCR80.DLL nicht gefunden wird. Ja und das stimmt, denn diese DLL kann nicht gefunden werden, da Sie nicht in den entsprechenden Manifesten definiert wurde.

Wie findet man so einen Fehler?
Herausbekommen habe ich das durch die Verwendung von DEPENDS.EXE. Damit konnte ich erstmal ermitteln wer, wen, wann laden möchte und wo das Laden letzten Endes fehlschlägt.
Dann habe ich die entsprechenden Module (DLLs und EXE Dateien) in den Resource-Editor geladen. Dort habe ich die entsprechenden Manifeste kontrolliert.

Nachtrag 22.03.2007 (als Kommentar wird es evtl. übersehen)
Ich habe aktuell auch in einem anderen Fall ähnliches herausbekommen. Hier wurde auch eine alte ZLib-Release Version (und andere) in ein Debug Projekt eingebaut. Nur waren diese Libraries im Projekt nicht mit VS-2005 kompiliert worden, denn sonst wären entsprechende Manifest Einträge eingeflossen. Soweit ich das Projekt sehen konnte wurde _CRT_NOFORCE_MANIFEST auch nicht verwendet, was die Erzeugung der Manifest Einträge verhindert hätte.
Das Resultat auch hier. Eine MSVCRT80.DLL wird vom Linker verlangt, aber es existiert kein Manifest dazu. Die entsprechende gleiche Fehlermeldung auch hier.
Ein Rebuild der entsprechenden Libraries und des Projektes lies das Programm dann zwar starten, aber dennoch wurden in diesem Falle gleichzeitig Debug-CRT und Release-CRT verwendet, was sicher nicht im Sinne der Programmierer war.

Wir lernen daraus wieder einmal: Achte streng auf die Trennung von Release und Debug Libraries. 😉

Gründe für den R6034 bei der VC 8.0 DLL CRT

Warum lässt sich die neue VC 8.0 CRT eigentlich nicht ohne Manifest verwenden?
Schauen wir uns also mal an was passiert wenn eine Applikation oder eine DLL geladen wird, die die VC 8.0 CRT als DLL verwendet:

Die DllMain der CRT wird aufgerufen. Bei der C-Runtime DLL ist dies die Funktion _CRTDLL_INIT die sofort die Funktion __CRTDLL_INIT aufruft.

Diese Funktion sorgt nun der Reihe nach dafür, dass:

die aktuelle Windows Version bestimmt wird
der Heap initialisiert wird
die TLS Bereiche für multithreading angelegt werden
das Environment und die Befehlszeile bestimmt werden
die MBCS Umwandlungstabellen angelegt werden
alles was mit atexit, floating-point math etc. initialisiert wird
und… jetzt wird es spannend… die Funktion _check_manifest aufgerufen wird.

In der Funktion _check_manifest wird der Code ausgeführt der zum Runtime Fehler R6034 „The application has attempted to load the runtime library incorrectly. Contact support for more information“ führen kann, nämlich genau dann, wenn diese Funktion FALSE zurück gibt.

Was macht diese Funktion nun?
Im Source-Code der CRT ist dies wunderbar dokumentiert:

if (pre-fusion OS)
return TRUE; [no need to check]
Das bedeutet nichts anderes, als das die nachfolgenden Tests nur auf XP/Vista/2003 und folgenden OS durchgeführt werden. Also im Klartext unter Windows 2000 kann dieser Runtime Error nicht auftreten.
if dll is being loaded by instrumented-mscoree.dll.
return TRUE;
OK. Ein Speziallfall. Im Kontext der .NET CLR und des Profilers ist auch ales erlaubt. Also wenn sich MSCoree.dll (Microsoft .NET Runtime Execution Engine) und PGORT80.dll (Profile Guided Optimization Instrumentation Runtime) im Speicher befinden ist auch alles paletti.
if (dll is loaded from system32)
return FALSE;
Dies ist interessant. In keinem Fall darf diese DLL im Windows\System32 stehen! Oder wenn Sie von dort geladen wird fielgt einem der R6045 um die Ohren.
if (!(loaded through a manifest))
return FALSE;
Hier wird über die Funktion FindActCtxSectionStringW geprüft ob diese DLL über ein Manifest geladen wird. ActCtx ist die Abkürzung für Activation Context.
Wurde kein solcher Activation Context gefunden (also kein Manifest), dass für diese DLL verantwortlich ist, dann heißt das auch R6045.
if (loaded from %SystemRoot%\WinSxS)
return TRUE; [loaded from the WinSxS cache]
Wird die DLL aus den Side by Side Verzeichnissen geladen ist schon alles gut.
Aber auch das geht nur mit gültigem Manifest.
if (manifest is in the same folder as the dll)
return TRUE;
Auch das ist interessant. Das Manifest muss zwingend im selben Verzeichnis wie diese DLL liegen, denn sonst sind wir fertig
return FALSE; [loaded with another manifest]
und nun schlägt das Laden fehl, da das Manifest offensichtlich nicht im DLL Verzeichnis liegt. Auch hier ein R6045.

Zurück noch mal zum Fall 2. Was macht dieser Test „if dll is being loaded by instrumented-mscoree.dll“? Er macht nichts anderes als zu prüfen ob die beiden DLLs im Speicher sind.

BTW: Man könnte nun ganz frech zwei leere DLLs mit diesen Namen erzeugen und diese in ein Projekt implizit laden lassen… und siehe da, die Applikation benötigt auf einmal kein Manifest mehr…
Aber warum sich das ganze verbietet ist auch klar. DLLs mit den oben genannten Namen zu erzeugen, kann ganz schön verwirrend und problematisch werden.
Und warum zwei leere DLLs in einen Prozess laden, wenn es reicht ein Manifest zu ergänzen? 😉

VS-2005 SP1 für Vista bringt kein Update für die MT.EXE

In meinem Beitrag UAC Trustinfo Manifest in ein VC-2005 SP1 Projekt einfügen habe ich berichtet wie man auf einfache Art und Weise ein UAC-Trustinfo-Manifest in ein VS2005 Projekt einbauen kann.

Dazu musste jedoch die MT.EXE aus dem Vista SDK in das entsprechende VC-Programmverzeichnis kopiert werden.

Ich hatte dies auch als Bug gemeldet und habe gehofft, dass dies auch im VS2005 SP1 für Vista noch behoben wird. Dem ist aber nicht so.
Die MT.EXE bleibt unverändert die Datei aus dem SP1 für VS2005. Und damit verbunden bleibt auch weiterhin das Versions Chaos. Wie schon berichtet haben beide Versionen aus dem Vista SDK und dem VS2005 SP1 die gleiche Versionsnummer. Wobei aber nur die Version aus dem Vista-SDK tut was man von ihr erwartet.

UAC und CreateNamedPipe mit lpSecurityAttributes==NULL

Das Leben steckt einfach voller Überraschungen. Da hat man einen Service der im LocalSystem Account läuft. Mit diesem Service wird über Named Pipes kommuniziert.

Das Programm, das diesen Service steuert soll nur für Administratoren verfügbar sein und greift lesend und schreibend auf diese Pipe zu. Der Admin nutzt dieses Programm oft, muss man dazu sagen.

In der Vergangenheit war da nicht viel zu tun. Einfach lpSecurityAttributes auf NULL setzen und OK. Der Admin hat dann einfach das Steuerungsprogramm gestartet und war glücklich.
Nun unter Vista läuft aber das Steuerungsprogramm nicht mehr mit administrativen Privilegien.

Ist das Programm nicht Vista aware (also hat kein Trustinfo Manifest), dann hat man keinen Zugriff auf die Pipe. Den in diesem Fall wird der Admin Token ausgefiltert!
Ist es Vista aware und man setzt asInvoker als Trustinfo, dann hat man auch keinen Zugriff. Logo.
Nur requireAdministrator führt zum gewünschten Ziel. Natürlich wieder mit der (manchmal) lästigen Meldung für ein Programm das häufig benutzt wird.

—
❗ Also liebe Programmierer Gemeinde! Bitte die SECURITY_ATTRIBUTES richtig ausfüllen mit einer DACL die eben nicht mehr nur den lokalen Admin enthält. Diese bei CreateNamedPipe verwenden und dann kann das Programm auch normal mit asInvoker gestartet werden.

Ach ja! Und ehe ich es vergessen ein NULL DACL ist hier nicht im Sinne des Erfinders… 🙂

😐 Insgesamt ärgerlich:
Man möchte es dem Benutzer möglichst einfach machen Programme zu nutzen. Der Vista-Admin-Privileg Dialog stört da manchmal (nicht immer). Also was macht man? Man setzt die Rechte für die Names Pipes und andere Objekte dieser Welt herunter, weil der Admin Token eben nicht mehr Bestandteil der Rechte ist für Programme die mit asInvoker gestartet werden.
Die Folge: Die Programme werden mit weniger Sicherheitsschranken gebaut, als zuvor.
War das im Sinne des Erfinders?

BTW: Da man sich mittlerweile schon blind angewöhnt hat, diesen Dialog zu bestätigen kann man sich fragen ob da noch ein Sicherheitsaspekt verbleibt, weil keiner mehr liest, welches Programm eigentlich administrative Rechte haben will.

Notwendigkeit von Manifesten für DLL’s mit VC-2005

Durch eine Anfrage in meiner Lieblingsgruppe microsoft.public.de.vc bin ich auf folgende interessante Frage gestoßen: Benötigt eine DLL die mit VC-2005 erzeugt wurde ein Manifest?

Nun wie viele Antworten im Leben lässt sich dies nicht eindeutig mit Ja oder Nein beantworten.

Nein! Es wird kein Manifest benötigt, wenn die CRT statisch gelinkt wird. In diesem Fall wird auch kein Manifest benötigt zumindest nicht für die CRT, was nicht heißt, dass nicht auch andere Assemblies per Manifest angebunden werden müssen.

Nein! Wenn die EXE-Datei bereits über ein Manifest verfügt und eine CRT-DLL mit gleichem Namen lädt, hier also z.B. die MSVCR80.DLL. In diesem Fall kann man sich ein Manifest sparen. Es kann aber hier spannend werden, weil die entsprechende DLL natürlich so nicht beeinflussen kann dir 8.0 CRT als SP1 oder RTM zu nutzen. Aber vermutlich ist das sowieso egal.

Ja! Die DLL benötigt ein Manifest, wenn ein beliebiges Programm die DLL nutzt. Zum Beispiel eines, das die CRT statisch linkt, oder das mit einer älteren VC Version erzeugt wurde. In diesem Fall muss die DLL zwingend ein Manifest haben. Und jetzt wird es noch strenger. Wird die DLL per LoadLibrary geladen, dann muss dieses Manifest sogar embedded sein! 🙄
Externe Manifeste bei DLLs werden nur beim impliziten Laden berücksichtigt. Wird eine DLL mit LoadLibrary geladen, dann werden nur eingebette Manifeste berücksichtigt.

❗ Falle: Hat die DLL kein Manifest wird immer garantiert, dass die CRT Version von EXE und DLL passen. Man kann also gefahrlos Speicher in der DLL allozieren und in der EXE freigeben und umgekehrt. Oder eben auch CRT Objekte austauschen. Nutzt die DLL ein eigenes Manifest besteht die Möglichekit, dass EXE und DLL eine unterschiedliche CRT verwenden! Und noch spannender wird es wenn eine EXE mit CRTx eine DLL1 benutzt die per Manifest CRTy verwendet und diese nun eine DLL ohne Manifest lädt… Ja es wird die CRT der EXE verwendet…

Ja ja. Wir haben dank der Manifeste nun keine DLL Hölle mehr. Wir haben eine Manifest Hölle 😀

Meine Empfehlung daher:

Wenn es eigenständige kleine Module sind, dann statisch gegen die CRT linken.
Ansonsten immer ein Manifest einbetten, wenn die DLL eigenständig genutzt wird!
Wird die DLL im Kontext einer bestimmten EXE(s) Datei verwendet, sollte nur die EXE(s) ein Manifest haben.
In jedem Fall darauf achten, dass gleiche CRT Versionen verwendet werden. RTM, SP1 und irgendwann wahrscheinlich SP2 werden hier Konflikte möglich machen.
MFC Extension DLLs müssen zwingend mit der selben MFC Version (RTM oder SP1) verwendet werden!

Stoff zum weiterlesen:
Isolated Applications and Side-by-side Assemblies

Besonders lesenswert hier der Beitrag von Nicola Dudar:
How to Debug ‚The System cannot Execute the specified program‘ message

Vista und die Notwendigkeit eines Manifestes für die UAC

Bei den vorbereiten von Software für Vista (Certified for Vista) ist mir die UAC (User Access Control) untergekommen. Unter Vista verschärft sich das ganze noch einmal gegenüber Windows 2000.

Einen der wichtigsten Punkte möchte einfach mal hier darlegen.
Unsere Software ist so geschrieben, dass ein Admin entsprechende Einstellungen in bestimmten Dateien im Programmverzeichnis ablegen kann und auch Einstellungen vornehmen kann die in HKLM abgelegt werden. Unter anderem dienen diese Dateien/Registry Einstellungen eben zur Kontrolle von Services und IPC. Sie müssen eben in einem allgemein zugänglichem Bereich liegen. Das ist ja nichts ungewöhnliches.

Brav wie wir sind haben wir entsprechende Prüfungen eingebaut und sagen dem Anwender, wenn er keine Rechte hat in HKLM zu schreiben, oder die entsprechenden Dateien im Programmverzeichnis zu ändern, z.B. INI Dateien die mit WritePrivateProfileString geschrieben werden.

Vista ist es nun egal, dass wir brave Entwickler sind. Vista behandelt uns per UAC Richtlinie wie einen Bösewicht und leitet alle Änderungen in den lokalen Bereich des Anwenders. Meine Software hat keine Chance zu erkennen, dass das schreiben in HKLM und den Programm-Datei Ordner eigentlich nicht erlaubt ist.

Man muss also zwingend ein Manifest für die UAC hinzufügen:

<?xml version=“1.0″ encoding=“utf-8″?>
<assembly xmlns=“urn:schemas-microsoft-com:asm.v1″ manifestVersion=“1.0″>
<trustInfo xmlns=“urn:schemas-microsoft-com:asm.v3″>
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level=“asInvoker“ />
      </requestedPrivileges>
    </security>
</trustInfo>
</assembly>

Erst mit diesem Manifest verhält sich meinem Programm wieder so, wie ich es auch erwarte!

Eine gute Anleitung hierfür:
– How To: Tell Vista’s UAC What Privelege Level Your App Requires
http://channel9.msdn.com/Showpost.aspx?postid=211271

Weitere Infos, Dokus und Hilfsprogramme:
– Understanding and Configuring User Account Control in Windows Vista
http://technet.microsoft.com/en-us/windowsvista/aa905117.aspx
– Windows Vista Application Development Requirements for User Account Control Compatibility
http://www.microsoft.com/downloads/details.aspx?FamilyID=BA73B169-A648-49AF-BC5E-A2EEBB74C16B&displaylang=en
– Microsoft Application Verifier
http://www.microsoft.com/downloads/details.aspx?familyid=BD02C19C-1250-433C-8C1B-2619BD93B3A2&displaylang=en
– Microsoft Standard User Analyze
http://www.microsoft.com/downloads/details.aspx?familyid=DF59B474-C0B7-4422-8C70-B0D9D3D2F575&displaylang=en