Warum l\u00e4sst sich die neue VC 8.0 CRT eigentlich nicht ohne Manifest verwenden?
\nSchauen wir uns also mal an was passiert wenn eine Applikation oder eine DLL geladen wird, die die VC 8.0 CRT als DLL verwendet:<\/p>\n
Die DllMain der CRT wird aufgerufen. Bei der C-Runtime DLL ist dies die Funktion _CRTDLL_INIT die sofort die Funktion __CRTDLL_INIT aufruft.<\/p>\n
Diese Funktion sorgt nun der Reihe nach daf\u00fcr, dass:<\/p>\n
In der Funktion _check_manifest wird der Code ausgef\u00fchrt der zum Runtime Fehler R6034 „The application has attempted to load the runtime library incorrectly. Contact support for more information“ <\/em>f\u00fchren kann, n\u00e4mlich genau dann, wenn diese Funktion FALSE zur\u00fcck gibt.<\/p>\n Was macht diese Funktion nun? Zur\u00fcck noch mal zum Fall 2. Was macht dieser Test „if dll is being loaded by instrumented-mscoree.dll“<\/em>? Er macht nichts anderes als zu pr\u00fcfen ob die beiden DLLs im Speicher sind.<\/p>\n BTW: Man k\u00f6nnte nun ganz frech zwei leere<\/em> DLLs mit diesen Namen erzeugen und diese in ein Projekt implizit laden lassen… und siehe da, die Applikation ben\u00f6tigt auf einmal kein Manifest mehr… Warum l\u00e4sst 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 … \u201eGr\u00fcnde f\u00fcr den R6034 bei der VC 8.0 DLL CRT\u201c <\/span>weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[19,3],"tags":[69,58,36],"class_list":["post-42","post","type-post","status-publish","format-standard","hentry","category-crt","category-programmieren","tag-manifest","tag-uac","tag-vs-2005"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts\/42","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/comments?post=42"}],"version-history":[{"count":0,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts\/42\/revisions"}],"wp:attachment":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/media?parent=42"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/categories?post=42"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/tags?post=42"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nIm Source-Code der CRT ist dies wunderbar dokumentiert:<\/p>\n\n
\n\u00a0 return TRUE; [no need to check]<\/em>
\n<\/strong>Das bedeutet nichts anderes, als das die nachfolgenden Tests nur auf XP\/Vista\/2003 und folgenden OS durchgef\u00fchrt werden. Also im Klartext unter Windows 2000 kann dieser Runtime Error nicht auftreten.<\/li>\n
\n\u00a0 return TRUE;
\n<\/strong><\/em>OK. Ein Speziallfall. Im Kontext der .NET CLR und des Profilers ist auch ales erlaubt. Also wenn sich MSCoree.dll<\/em> (Microsoft .NET Runtime Execution Engine) und PGORT80.dll<\/em> (Profile Guided Optimization Instrumentation Runtime) im Speicher befinden ist auch alles paletti.<\/li>\n
\n\u00a0 return FALSE;
\n<\/strong><\/em>Dies ist interessant. In keinem Fall darf diese DLL im Windows\\System32<\/em> stehen! Oder wenn Sie von dort geladen wird fielgt einem der R6045 um die Ohren.<\/li>\n
\n\u00a0 return FALSE;<\/strong>
\n<\/em>Hier wird \u00fcber die Funktion FindActCtxSectionStringW<\/em> gepr\u00fcft ob diese DLL \u00fcber ein Manifest geladen wird. ActCtx<\/em> ist die Abk\u00fcrzung f\u00fcr Activation Context.
\nWurde kein solcher Activation Context gefunden (also kein Manifest), dass f\u00fcr diese DLL verantwortlich ist, dann hei\u00dft das auch R6045.<\/li>\n
\n\u00a0 return TRUE; [loaded from the WinSxS cache]<\/strong>
\n<\/em>Wird die DLL aus den Side by Side Verzeichnissen geladen ist schon alles gut.
\nAber auch das geht nur mit g\u00fcltigem Manifest.<\/li>\n
\n\u00a0 return TRUE;
\n<\/strong><\/em>Auch das ist interessant. Das Manifest muss zwingend im selben Verzeichnis wie diese DLL liegen, denn sonst sind wir fertig<\/li>\n
\n<\/em>und nun schl\u00e4gt das Laden fehl, da das Manifest offensichtlich nicht im DLL Verzeichnis liegt. Auch hier ein R6045.<\/li>\n<\/ol>\n
\nAber warum sich das ganze verbietet ist auch klar. DLLs mit den oben genannten Namen zu erzeugen, kann ganz sch\u00f6n verwirrend und problematisch werden.
\nUnd warum zwei leere DLLs in einen Prozess laden, wenn es reicht ein Manifest zu erg\u00e4nzen? \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"