![[HaBo]](/styles/default/logoklein.png){kind=small}
Hallo, ich habe folgendes Problem, das ich bislang nach einem Tag selbständigen Frickelns nicht gelöst bekommen habe - vielleicht gibts ja jemanden, der zumindest Ideen liefern kann...
Ich hatte gerade Teile der IDE MSVC 2005 neu installiert, speziell das Packet "Microsoft Plattform SDK Windows Server 2003 R2" (das letzte, welches ohne spezielle Elemente für Windows 7++ und allem möglichen nicht erwünschten Schnickschnack ausgeliefert worden war). Steht alles noch bei MS zum Download bereit, so ist das ja nicht.
Nun ist die Installationsprozedur dieses Dingens aber offenbar in zwei Teile geteilt - was immer sich da ein durchgeknallter Programmierer bei Microsoft gedacht haben mochte: Nachdem man als Admin das Packet installiert hat, möchte dieses unter jedem Benutzerkonto beim nächsten Login des jeweiligen Benutzers einen zweiten Installationsschritt ausführen.
Nun ist...
1.) ...mein System, um das es geht, gründlich und aufwendig und seit seiner ersten Einrichtung vor vielen Jahren eben genau gegen solche Installations-Aktionen unter eingeschränkten Konten geschützt. Der Installer kann unter einem beliebigen normalen Benutzerkonto zwingend nur fehlschlagen und tut es auch - ganz wie zu erwarten. Solcherart krass jeder Sicherheitsphilosophie zuwiderlaufende Installationsmentalität ist ja nun nicht nur bei Microsoft verbreitet, und ich habe durchaus gelernt, damit umzugehen, zum Beispiel, indem ich temporär Anpassungen der Zugriffsrechte - gegebenenfalls mittels Script - vornehmen lasse. Aber in diesem Fall kommt erschwerend hinzu, daß die Microsoft-Programmierer die Verankerung dieses Installer-Schrittes in den Autostarts des Systems dermaßen versteckt und zudem nirgendwo dokumentiert haben (ich habe einen Tag lang mit den Sysinternals Tools herumexperimentiert und das Technet sowie weltweit die Technik-Foren rauf und runter gesucht und keinerlei Treffer für mein Problem gefunden; auch eine Registry-Suche mit Parametern, die unter dem Sysinternals Process Explorer erkennbar sind, brachte keinen Treffer), daß mir hier schlicht die Hände gebunden sind.
2.) ...dieser Nach-Installations-Schritt überhaupt nicht notwendig, weil die IDE längst mit dem SDK läuft (ich hatte nach der Installation im Admin-Modus einfach die Pfade, die das Teil nicht von selbst in der IDE-Konfiguration erkannt und angepaßt bekommen hatte - wofür ich eine Portion Verständnis und Toleranz mitbringe: schließlich lief die Installation ja unter dem Admin-Konto, während die Pfadeinstellungen Sache der Benutzerkonten sind -, selbst eingestellt und damit war's gut).
Zudem zeigt dieses Teil einen penetranten Wiederholungsstart mit einer Endlosschleife, wenn es erstmal damit begonnen hat:
1. Es verlangt nach dem Installationsarchiv, welches durchaus dort befindlich ist, wo es mit seinem einstellbaren Pfad hinzeigt...
2. Es meckert an, daß es das Installationsarchiv nicht finden kann - was schlicht ein falscher Fehler ist, denn finden tut es das Ding ja, es kann (und soll) es nur nicht mit Admin-Rechten ausführen, was es kurz probiert und dann falsch befehlert...
3. Es MUSS ZWINGEND an dieser Stelle "abgebrochen" werden (weil es sonst an diesem Punkt in einer ersten Endlosschleife sitzt)
4. Nach dem Rollback wird es SOFORT in einer zweiten Endlosschleife erneut gestartet. (Im Hintergrund gibt es einen Mutter-Prozeß von msiexec.exe, der unter dem System-Konto läuft, der seinerseits offenbar endlos einen Kind-Prozeß unter dem Benutzerkonto startet, der offenbar die Aufgabe HÄTTE, diesen Autostart-Eintrag nach erfolgreichem Abschluß zu beseitigen. Auch das ist offensichtlich ein Programmierfehler...)
==============
Mein Problem lautet also letztlich: Da ist irgendwo ein totaler Nonsense-Installationsschritt (komplett sinnlos, nicht benötigt, inhaltlich von mir zu Fuß eh schon abgehandelt und zudem inhaltlich sowieso nur trivialer Stuß) in irgendwelchen total versteckten (von Microsoft nicht dokumentiert, in Foren weltweit bislang nicht wiederzufinden) benutzerspezifischen Autostart-Punkten des Systems verankert worden, der naturgemäß eben wegen einer "ordentlichen" Konfiguration des Systems niemals erfolgreich durchlaufen und sich selbst dadurch auch niemals wieder aus diesem Autostart löschen kann, und der zu guter Letzt auch noch in einer Endlosschleife ausgeführt wird.
Ich würde gern erfahren, ob irgendwer dieses Verhalten bei sich auch schon mal beobachtet hat und es eventuell irgendwie abgestellt bekommen hat - weil das ein Verhalten ist, daß ich keinem anderen Familienmitglied zumuten will und es sowieso einfach eine Frechheit von Seiten von Microsoft darstellt, eine Installationsprozedur dermaßen zu verhunzen.
Ach ja: Eine Anfrage beim Technet von Microsoft ist unmöglich, weil deren Forum zwingend Javascript voraussetzt, welches - natürlich - nicht kompatibel mit dem Javascript-Standard vom Rest der Welt ist und offenbar zwingend einen aktuellen Internet-Explorer voraussetzt, der bei mir mitnichten jemals zu was anderem als Systemupdates die Erlaubnis bekommen wird. Auch in Webseitengestaltung sind die Microsoft-Leute leider bis heute absolut unfähig, simple Standards einzuhalten. Ja, also: Deshalb kann ich die Frage dort nicht stellen, obwohl die dort natürlich besser aufgehoben wäre...
==============
P.S.: Nochwas zu Details dieses ominösen (regelrecht virulent anmutenden - es stellt echt eine bodenlose Frechheit dar, solch einen Schund zu programmieren, gelle?!) Verhaltens des Windows-Installers:
Der Programmcode dieses Gerätes wird vom jenem msiexec.exe-Prozeß, welcher unter dem jeweiligen Benutzerkonto läuft, offenbar in FREMDE (beliebige) Programme injizziert, die sonst noch so auf dem Desktop laufen. Bei mir zum Beispiel wird "GPGTray.exe" benutzt. Dieses verliert seine normale Funktionalität (das Icon im Systemtray verschwindet, es kann nicht mehr benutzt werden). Versucht man im Sysinternals Process Explorer, daß Fenster des MS-Installers einem Prozeß zuzuordnen, wird eben dieser gekaperte Fremd-Prozeß angezeigt. Erst wenn DIESER gekillt wird, verschwindet das Installer-Zeug - vorübergehend für diesen einen Login - von der Benutzeroberfläche.
Wenn ich nicht genau wüßte, daß das Zeug von Microsoft kommt, verifiziert ist und ich ja nur einer von vielen tausenden Programmierern bin, die es verwenden (allerdings recht wahrscheinlich der einzige unter denen, der sein Entwicklungssystem sicherheitstechnisch dermaßen konsequent zugenagelt hat), würde ich das glatt für den krampfhaften Versuch eines Trojaners halten, irgendwie etwas im System über den Mißbrauch eines anderen Programms hinweg zur Ausführung zu bringen.
================
Nochmal ein P.S.: Nach ner Weile hatte ich Bedarf, das GPG zu benutzen. Da ich das ja seit gestern immer beim Login abschalte, mußte ich es mal ausnahmsweise aus dem Startmenü heraus anschmeißen. Und siehe da: Sobald ich dieses starte, kommt nicht etwa GPGTray, sondern dieser Windows-Installer wieder zum Vorschein. Das halte ich inzwischen für krank. Ich vermute mal, da hat sich irgendwas anderes in der Registry verhakt. Weil: GPG und der Windows Installer sind ja nun eigentlich SOWAS von getrennten Welten... Ich bin gerade dabei, daß näher zu untersuchen...
...Wenn ich die durch den GPG-Start parasitär ausgelösten "msiexec.exe"-Prozesse hinreichend schnell abschieße, bleibt letztlich der GPGTray wieder stehen, so daß er benutzbar ist (auch das Tray-Icon erscheint dann wieder)...
...Also ich bin vorerst irritiert: Sämtliche GPG-Programme AUSSER GPGConfig - aber sonst kein einziges Programm im System - zeigen gleiches Verhalten: Alle starten sie den Windows-Installer.
Dabei zeigt sich über Sysinternals Procmon eine Gemeinsamkeit im Startprozeß: Alle diese GPG-Programme kämmen die Registry nach Einträgen unter der Kennung "{000C101C-0000-0000-C000-000000000046}" - das ist die für den MSI-Server - durch. Danach folgt ein kurzes Übergeben desselben Scans an den SVCHost, dann folgt der Start des MS-Installers mit dem bekannten Unsinn in der bekannten Endlosschleife.
...Weiter geht's: Hab per Zufall entdeckt, daß der MSInstaller Logs im User-Temp-Verzeichnis hinterläßt.
Dort finde ich erstmal bestätigt, daß dieser Schweinehund auf magische Weise automatisch mitgestartet wird, wenn gewisse andere Programme gestartet werden - gleich in der ersten Log-Zeile:
=== Verbose logging started: 22.07.2012 05:09:31 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: D:\Werkzeug\System\Security\PGP\GPGtools.exe ===
Dann gehen die bodenlosen Frechheiten aber erst richtig los...
Obwohl auf meinem System die suizidöse Einstellung "AlwaysInstallElevated" NICHT gesetzt ist, ...
MSI (s) (AC:C0) [05:09:31:567]: Machine policy value 'AlwaysInstallElevated' is 0
...erlaubt sich dieser Installer dies dennoch...
Running product '{9A0ED01E-FD18-457A-AB9C-0835DCDB17BB}' with elevated privileges: Product is assigned.
...weil er festgestellt, daß ich das VORHER IRGEDNWANN mal mit Admin-Konto gerunned hatte...
Product {9A0ED01E-FD18-457A-AB9C-0835DCDB17BB} is admin assigned: LocalSystem owns the publish key.
Wenn ich das so in der Logdatei lese, rollen sich mir die Fußnägel hoch.
Ich weiß noch lange nicht, was ich im Detail davon zu halten habe, aber der erste Eindruck ist desaströs.
================
Also, meine Vermutung, wie das ganze zusammenhängt, geht derzeit in folgende Richtung:
Aus irgendeinem mir unerklärlichen Grund ist das GPG-Zeugs so programmiert, daß es generell bei jedem Start den MS-Installer mitstartet, der mal eben gucken soll, ob nicht ein Patch für das GPG verfügbar ist. Normalerweise isses nicht, so daß dieser MS-Installer unmittelbar wieder beendet wird und die Applikation normal startet, so daß man von dem Zeug unter normalen Bedingungen auch nichts mitkriegt.
(P.S.: Das hängt wohl damit zusammen, daß das GPG-GUI in VisualBasic programmiert ist - auch eine Microsoft-Suppe - und die VB Runtime benutzt, die sich ihrerseits in den Tiefen des Systems an undokumentierten Features vergreift einschließlich unerlaubten automatischen Installationsorgien...)
JETZT aber hat sich von dem MSVC-Zeug irgendwie irgendwas als benutzerspezifischer Nach-Konfigurationsschritt "registriert", und während das MSI-Zeug vom GPG treudoof mitgestartet wird, entdeckt es diesen Schrott und versucht, ihn auszuführen. Ich werde jetzt mal das Plattform-SDK wieder runterschmeißen und gegentesten, ob da was dran ist...
VORHER hatte ich allerdings nochmal testen wollen, ob mit dem Setzen von
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer:
isableUserInstalls
das Problem sofort abzustellen wäre. Bei der Gelegenheit entdecke ich zufällig, daß auf dem System
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer::EnableAdminTSRemote
gesetzt ist (jetzt war). Da hatte sich Microsoft was ganz tolles gedacht, um von einer Terminal-Sitzung aus in fremde Systeme eingreifen zu dürfen. Wobei zugegebenermaßen noch ein paar Voraussetzungen dazugehören (ein Admin-Konto bspw.). Mag ja eine begrenzt sinnvolle Idee gewesen sein, um DAU's vom Support helfen zu lassen - WENN denn das System ansonsten für illegale remote Sessions abgedichtet wäre. Was ich im allgemeinen hochgradig bezweifle. Jedenfalls halte ich sowas (Hintertürchen einrichten) generell für eine Frechheit. Ich gehe aber davon aus, daß von sowas auch nach mehreren Jahren Systemwartung noch etliche Einträge im System herumgeistern werden...
...Und "DisableUserInstalls" bringt gar nix. Jedenfalls nicht ohne Neustart (ist ein solcher eventuell notwenig?)
Beim Versuch des Neustarts werden mir neu verfügbare Updates vom Windows Update um die Ohren gehauen... Also ERSTMAL zwischendurch rüber ins Admin-Konto und dort die Updates angucken und gegebenenfalls einspielen...
Dabei wird jetzt genauso wie unter dem normalen Benutzerkonto diese Installation des PSDK gestartet... Die sagt mir nun, daß der User "..." (von dessen Konto ich eben rüber kam) "has previously initiated..." (eine Frechheit, so eine falsche Tatsachenbehauptung, gelle?!) "...an install for product 'Microsoft Platform SDK (R2) ()3790.2075). That user will need to run that install again..." (aha, da haben wir's erstmal offiziell, wo's herkommt) "...before they..." (Einzahl und Mehrzahl seien vollig egal in englandiges Sprach) "...can use that product..."
Eh - nicht mal Rechtschreibung beherrschen die bei MS... Kein Wunder, daß die Programme wie Kraut und Rüben funktionieren...
Das Update, welches da wartet, ist das Service Pack zur MS .Net Runtime. DAS werde ich jetzt NICHT installieren, weil das in der Vergangenheit AUCH schon IMMER Probleme bereitet hat (eine weitere Endlosschleife von ewiglich fehlschlagenden Installationsversuchen), die ich JETZT NICHT unter die ohnehin schon vorhandenen Fehler des MS-Installers mischen möchte...
Freude nach dem Neustart: Jetzt sagt mir auch der - immer noch - unter dem Benutzerkonto gestartete MSI-Schrott, daß der Admin eine Installation dieses PSDK-Schrotts gestartet hätte, welches er nicht mehr nutzen könne würde, bis er diese Installation nochmal ausgeführt hätte. Jetzt haben wir also eine sich gegenseitig befütternde Endlos-Schleife zum Quadrat. Eh: Die Programmierer, die sowas verbrechen, gehören doch auf der Stelle lobotomiert, gell?!
================
So, nach einer Entspannung von diesem versauten Rechtemißbrauch durch Microsoft-Produkte habe ich einfach mal dem "msiexec.exe" das Recht zum Ausführen durch Benutzer und System entzogen - so daß nur noch das Admin-Konto das Ding starten darf. Damit ist jetzt für den Moment erstmal Ruhe eingekehrt. Dafür noch zwei kleine Batchdateien vorbereitet, die analog zur Execution Policy dem msiexec die Rechte BEI BEDARF wiedergeben und ebenso schnell wieder entziehen können.
Eine RICHTIGE Lösung ist das jedoch nicht: Dazu wäre es notwendig, die tatsächliche Ursache der versaubeutelten Installation herauszukriegen. Da bin ich immer noch gespannt auf Ideen (und weiter selbst am suchen)...
Scheint ja im Moment echt tote Hose hier im Forum zu sein...
So... Jetzt wurden aber ganz andere Kräfte geweckt... Jetzt startet beim Login der "WGATray" (Windows will wohl jetzt, wo msiexec vom System nicht mehr ausgeführt werden kann, eine Systemänderung erkannt haben), wird allerdings sofort danach wieder beendet (nur der Process Explorer von Sysinternals verrät, daß da vor ein paar Sekunden was gelaufen war). Außerdem poppen zwischendurch ganz kurz mehrere Fensterchen auf - wohl weil derjenige, der - wie auch immer (ist ja streng geheim alias undokumentiert) - dieses msiexec krampfhaft zu starten versucht, diese Versuche natürlich noch lange nicht aufgegeben hat...
=== Verbose logging started: 22.07.2012 19:23:21 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: C:\WINDOWS\Explorer.EXE ===
Nun ja: GPG ist offenbar nicht das einzige Programm, das irgendwie den MS-Installer automatisch auf irgendwelche Updates oder Nachinstallationsschritte abklopft...
Allerdings bleibt das jetzt zumindest nach wenigen Millisekunden hängen:
MSI (c) (A0:0C) [19:23:21:828]: Es konnte keine Verbindung mit dem Server hergestellt werden. Fehler: 0x80070005
Gut so für's erste...
==============
Fortsetzung auf ner alternativen Linie: Im Internet fand sich ein Hinweis auf ein gewisses "Fixit" von Microsoft (Fix problems with programs that can't be installed or uninstalled), welches nach vager, weitgefaßter Interpretation eventuell auch in der Lage sein können müßte, bei meinem Problem auszuhelfen (letztlich will ich ja von dem blöden Installer gar nichts mehr wissen).
Der Versuch, das betreffende Programm ("Microsoft-Installer-Fixit-portable.exe") zu starten, resultiert über die Zwischenstufe, mal wieder etwas bei mir eigentlich mit dem Tode bestraftes zu versuchen (Das EIGENTLICH Programm über ein extrem verteiltes und - natürlich, wer würde irgendwas anderes erwarten? - undokumentiertes, noch nicht mal wenigstens knapp angedeutetes (nur die Firewall läuft im Hintergrund Amok) Herunterladen von irgendwelchen nicht näher definierten weiteren Programmpaketen - wir erinnern uns bei sowas vage an das typische Verhalten von Viren und Trojanern, gell?! - im verbotenen Temp-Ordner abzulegen und dann dort im selben Zuge zur Ausführung bringen zu wollen, tsssss...), nachdem ich dieses zugelassen habe in der von Sarkasmus triefenden Meldung: 'Sie verfügen nicht über die erforderlichen Berechtigungen, um dieses Programm auszuführen.... Die Funktion "runas" wird von diesem Programm nicht unterstützt...'.
Klar: Ein fehlerhaft ausgewerteter Fehler in einem Programm, welches bei der Behebung eines fehlerhaft ausgewerteten Fehlers helfen sollen täte. Hatte ich was anderes erwartet? Nein, eigentlich nicht. Deshalb hatte ich diesen Versuch ja auch so lange hinausgezögert.
Wobei: Das Programm, was eigentlich ausgeführt werden soll, ist ja ein gänzlich anderes: Das kommt über insgesamt DREI Nachladestufen (Microsoft-Installer-Fixit-portable.exe -> MatsBoot.exe -> LaunchFixit.exe, wobei die Zwischenschritte mit den CAB-Dateien und deren an Umständlichkeit nicht mehr zu toppenden Entpackungen bereits weggelassen wurden) ins System (zwei davon hatte dieser "Fixit"-Witz immerhin zu nehmen geschafft).
Klar: Ein Programm, welches bei PROBLEMEN helfen soll, macht man bei Microsoft NATÜRLICH mindestens dermaßen künstlich aufgebauscht kompliziert, daß man zwingend einen bezahlten Service-Techniker von denen und eine Hotline zum lieben Gott persönlich benötigt, um überhaupt dieses Dingens in Benutzung nehmen zu können. Die wollen ja Geld sehen, kann man ja verstehen...
Sie HÄTTEN natürlich auch gleich das Zeug namens "LaunchFixit.exe", welches da auf der (für mich momentan scheinbar) letzten Stufe EIGENTLICH zur Ausführung gebracht werden sollte, samt seinen 20 Megabytes Daten in einem einfachen Archiv verpackt zur Verfügung stellen können, gell?! Wobei: Das HABEN die ja sogar: http://download.microsoft.com/downl...C-42D2-AC7F-8A6AD2920E6D/MatsOfflineSetup.cab
Aber indem ich das hier erwähne, begehe ich mit Sicherheit ein Urheber-Verbrechen, weshalb ich mit dem mindestens 1 Millionenfachen Strafmaß bedacht werden muß, welches man kassiert, wenn man Urheberverbrechen im industriellen Stil begeht... ...Sorry, ich schweife vom Thema ab...
...Ich hab jetzt einfach mal das "LaunchFixit.exe" direkt auszuführen versucht. Natürlich (ich hatte nicht wirklich was anderes erwartet) funktioniert es nicht ("Laufzeitfehler des Programms"). Beim näheren Untersuchen mit Procmon zeigt sich, daß dieses Ding genau dieselben Kapriolen schlägt wie der MS-Installer (dem er davon abhelfen sollte): Der unter dem Admin gestartete Prozeß startet seinerseits einen Prozeß unter dem System-Konto, der wiederum einen Prozeß unter dem Konto des aktuellen Desktop-Besitzers (also dem eingeschränkten Benutzer) aus einem temporären Verzeichnis heraus zu starten versucht - was selbstverständlich gar nichts anderes kann als nicht funktionieren.
Ich glaub, die haben die Trojaneritis bei Microsoft. Aber durchweg.
Irgendein Manager muß bei denen was falsch verstanden haben, daß die ihre Programmierer in den letzten Jahren dazu zwingen, solchen Schwachsinn zu fabrizieren. Weil: Ich kann mir nicht ausmalen, wie jemand von allein auf solche Ideen kommen sollte...
Wobei: So ganz klar ist das aus dem Procmon-Log auch wieder nicht: "Access Denied" tritt zwar an genau solchen Stellen auf, wo letztlich die "LaunchFixit.exe" unter dem Benutzerkonto mit Recht zum executen geöffnet werden soll, aber diese Aktion steht seltsamerweise in Verbindung mit Firewall-Aktionen, die im Gesamtlog keinen offensichtlichen Bezug zu den sonstigen Aktionen des Ursprungsprozesses haben...
Aber es scheint mir erstmal nicht sinnvoll, diese Schiene weiter zu verfolgen: Zuviel Aufwand!
==============
Ich glaube, ich komme der Sache langsam näher: Using Self-Healing to Your Advantage | eWall.org
Allerdings fehlt dort jede Erläuterung über die System-Mechanismen. Es wird alles anhand phänomenologischer Erscheinungen der Authoring-Software erklärt (schieb dies und das dort und dort hin)...
...Erstmal auf die längere Schiene geschoben: Erläuterungen zur Technik hinter der Fassade ist im ganzen Internet fast nicht zu finden, das bißchen (zum Beispiel Hinweise auf irgendwelche ominösen "advertising flags") hat bislang gar nichts gebracht (hab die zwar in den Windows-Installer-Hinterlassenschaften gefunden, aber konnte die Tips nicht nachvollziehen).
Beim Platform-SDK ist ja durchaus auch ein Satz MSI-Dokumentation dabei, habe ich gerade gesehen...
==============
Habe jetzt - nachdem alles andere versagt hatte - erstmal die Option probiert (einer der häufigsten Tips zu Problemen mit dem Installer hinsichtlich Endlosschleifen - ich bin da bei weitem nicht der einzige, aber die Erscheinungsformen sind doch arg vielfältig), das störenden Modul zu deinstallieren und dann nochmal neu zu installieren.
Da ich inzwischen ja ausreichend genau wußte, welche Erscheinungen so auftreten, konnte ich schnell und aussagekräftig testen:
Nach Deinstallation waren die parasitären Starts des Windows Installers beim Start zum Beispiel des GPG-Zeugs weg (fein!).
Nach Reinstallation waren sie wieder da.
Ach ja, übrigens: Diese hochgeistigen Microsoft-Install-Spezialisten haben doch glatt ein Office10-Verzeichnis kreieren lassen. Woher die die Weisheit nahmen, das Ding im Root-Verzeichnis meiner zweiten Festplatte anlegen zulassen, wird wohl auf ewig in den Annalen dieser Typen versteckt bleiben. Jeweils können die sich das dahin stecken!
Ich könnte natürlich auch nochmal einen krass härteren Weg gehen: Aus der Registry samt und sonders alles rausschmeißen, was irgendwie an dieses PSDK oder irgendwas damit zusammenhängendes erinnert. Allerdings tut es mir um die dafür zu verbratene Lebenszeit leid.
Ich nehm erstmal wieder die General-Abschaltung von msiexec...
...Neeee, ich mach das jetzt noch ganz anders: Ich lege jetzt einfach ein Archiv der installierten Dateien an, deinstalliere den Scheiß und kopiere anschließend die Dateien wieder zurück...
===============
Finally solved.
Die IDE meckerte noch zweimal von wegen, daß sie wieder mal "zur erstmaligen Benutzung initialisieren" müßte oder so ähnlich, aber dann war Ruhe im Karton und die Bibliotheken stehen ebenfalls alle zur Verfügung.
Amen!
(Hinterher fragt man sich immer wieder, warum man nicht gleich auf diese einfache Lösung gekommen ist: Die Ideen-Ansätze waren durchaus von Anfang an da, nur der Wille, etwas funktionsunfähiges unbedingt doch zur Funktion zu bringen, führte zeitweilig in die Irre...)
Ich hatte gerade Teile der IDE MSVC 2005 neu installiert, speziell das Packet "Microsoft Plattform SDK Windows Server 2003 R2" (das letzte, welches ohne spezielle Elemente für Windows 7++ und allem möglichen nicht erwünschten Schnickschnack ausgeliefert worden war). Steht alles noch bei MS zum Download bereit, so ist das ja nicht.
Nun ist die Installationsprozedur dieses Dingens aber offenbar in zwei Teile geteilt - was immer sich da ein durchgeknallter Programmierer bei Microsoft gedacht haben mochte: Nachdem man als Admin das Packet installiert hat, möchte dieses unter jedem Benutzerkonto beim nächsten Login des jeweiligen Benutzers einen zweiten Installationsschritt ausführen.
Nun ist...
1.) ...mein System, um das es geht, gründlich und aufwendig und seit seiner ersten Einrichtung vor vielen Jahren eben genau gegen solche Installations-Aktionen unter eingeschränkten Konten geschützt. Der Installer kann unter einem beliebigen normalen Benutzerkonto zwingend nur fehlschlagen und tut es auch - ganz wie zu erwarten. Solcherart krass jeder Sicherheitsphilosophie zuwiderlaufende Installationsmentalität ist ja nun nicht nur bei Microsoft verbreitet, und ich habe durchaus gelernt, damit umzugehen, zum Beispiel, indem ich temporär Anpassungen der Zugriffsrechte - gegebenenfalls mittels Script - vornehmen lasse. Aber in diesem Fall kommt erschwerend hinzu, daß die Microsoft-Programmierer die Verankerung dieses Installer-Schrittes in den Autostarts des Systems dermaßen versteckt und zudem nirgendwo dokumentiert haben (ich habe einen Tag lang mit den Sysinternals Tools herumexperimentiert und das Technet sowie weltweit die Technik-Foren rauf und runter gesucht und keinerlei Treffer für mein Problem gefunden; auch eine Registry-Suche mit Parametern, die unter dem Sysinternals Process Explorer erkennbar sind, brachte keinen Treffer), daß mir hier schlicht die Hände gebunden sind.
2.) ...dieser Nach-Installations-Schritt überhaupt nicht notwendig, weil die IDE längst mit dem SDK läuft (ich hatte nach der Installation im Admin-Modus einfach die Pfade, die das Teil nicht von selbst in der IDE-Konfiguration erkannt und angepaßt bekommen hatte - wofür ich eine Portion Verständnis und Toleranz mitbringe: schließlich lief die Installation ja unter dem Admin-Konto, während die Pfadeinstellungen Sache der Benutzerkonten sind -, selbst eingestellt und damit war's gut).
Zudem zeigt dieses Teil einen penetranten Wiederholungsstart mit einer Endlosschleife, wenn es erstmal damit begonnen hat:
1. Es verlangt nach dem Installationsarchiv, welches durchaus dort befindlich ist, wo es mit seinem einstellbaren Pfad hinzeigt...
2. Es meckert an, daß es das Installationsarchiv nicht finden kann - was schlicht ein falscher Fehler ist, denn finden tut es das Ding ja, es kann (und soll) es nur nicht mit Admin-Rechten ausführen, was es kurz probiert und dann falsch befehlert...
3. Es MUSS ZWINGEND an dieser Stelle "abgebrochen" werden (weil es sonst an diesem Punkt in einer ersten Endlosschleife sitzt)
4. Nach dem Rollback wird es SOFORT in einer zweiten Endlosschleife erneut gestartet. (Im Hintergrund gibt es einen Mutter-Prozeß von msiexec.exe, der unter dem System-Konto läuft, der seinerseits offenbar endlos einen Kind-Prozeß unter dem Benutzerkonto startet, der offenbar die Aufgabe HÄTTE, diesen Autostart-Eintrag nach erfolgreichem Abschluß zu beseitigen. Auch das ist offensichtlich ein Programmierfehler...)
==============
Mein Problem lautet also letztlich: Da ist irgendwo ein totaler Nonsense-Installationsschritt (komplett sinnlos, nicht benötigt, inhaltlich von mir zu Fuß eh schon abgehandelt und zudem inhaltlich sowieso nur trivialer Stuß) in irgendwelchen total versteckten (von Microsoft nicht dokumentiert, in Foren weltweit bislang nicht wiederzufinden) benutzerspezifischen Autostart-Punkten des Systems verankert worden, der naturgemäß eben wegen einer "ordentlichen" Konfiguration des Systems niemals erfolgreich durchlaufen und sich selbst dadurch auch niemals wieder aus diesem Autostart löschen kann, und der zu guter Letzt auch noch in einer Endlosschleife ausgeführt wird.
Ich würde gern erfahren, ob irgendwer dieses Verhalten bei sich auch schon mal beobachtet hat und es eventuell irgendwie abgestellt bekommen hat - weil das ein Verhalten ist, daß ich keinem anderen Familienmitglied zumuten will und es sowieso einfach eine Frechheit von Seiten von Microsoft darstellt, eine Installationsprozedur dermaßen zu verhunzen.
Ach ja: Eine Anfrage beim Technet von Microsoft ist unmöglich, weil deren Forum zwingend Javascript voraussetzt, welches - natürlich - nicht kompatibel mit dem Javascript-Standard vom Rest der Welt ist und offenbar zwingend einen aktuellen Internet-Explorer voraussetzt, der bei mir mitnichten jemals zu was anderem als Systemupdates die Erlaubnis bekommen wird. Auch in Webseitengestaltung sind die Microsoft-Leute leider bis heute absolut unfähig, simple Standards einzuhalten. Ja, also: Deshalb kann ich die Frage dort nicht stellen, obwohl die dort natürlich besser aufgehoben wäre...
==============
P.S.: Nochwas zu Details dieses ominösen (regelrecht virulent anmutenden - es stellt echt eine bodenlose Frechheit dar, solch einen Schund zu programmieren, gelle?!) Verhaltens des Windows-Installers:
Der Programmcode dieses Gerätes wird vom jenem msiexec.exe-Prozeß, welcher unter dem jeweiligen Benutzerkonto läuft, offenbar in FREMDE (beliebige) Programme injizziert, die sonst noch so auf dem Desktop laufen. Bei mir zum Beispiel wird "GPGTray.exe" benutzt. Dieses verliert seine normale Funktionalität (das Icon im Systemtray verschwindet, es kann nicht mehr benutzt werden). Versucht man im Sysinternals Process Explorer, daß Fenster des MS-Installers einem Prozeß zuzuordnen, wird eben dieser gekaperte Fremd-Prozeß angezeigt. Erst wenn DIESER gekillt wird, verschwindet das Installer-Zeug - vorübergehend für diesen einen Login - von der Benutzeroberfläche.
Wenn ich nicht genau wüßte, daß das Zeug von Microsoft kommt, verifiziert ist und ich ja nur einer von vielen tausenden Programmierern bin, die es verwenden (allerdings recht wahrscheinlich der einzige unter denen, der sein Entwicklungssystem sicherheitstechnisch dermaßen konsequent zugenagelt hat), würde ich das glatt für den krampfhaften Versuch eines Trojaners halten, irgendwie etwas im System über den Mißbrauch eines anderen Programms hinweg zur Ausführung zu bringen.
================
Nochmal ein P.S.: Nach ner Weile hatte ich Bedarf, das GPG zu benutzen. Da ich das ja seit gestern immer beim Login abschalte, mußte ich es mal ausnahmsweise aus dem Startmenü heraus anschmeißen. Und siehe da: Sobald ich dieses starte, kommt nicht etwa GPGTray, sondern dieser Windows-Installer wieder zum Vorschein. Das halte ich inzwischen für krank. Ich vermute mal, da hat sich irgendwas anderes in der Registry verhakt. Weil: GPG und der Windows Installer sind ja nun eigentlich SOWAS von getrennten Welten... Ich bin gerade dabei, daß näher zu untersuchen...
...Wenn ich die durch den GPG-Start parasitär ausgelösten "msiexec.exe"-Prozesse hinreichend schnell abschieße, bleibt letztlich der GPGTray wieder stehen, so daß er benutzbar ist (auch das Tray-Icon erscheint dann wieder)...
...Also ich bin vorerst irritiert: Sämtliche GPG-Programme AUSSER GPGConfig - aber sonst kein einziges Programm im System - zeigen gleiches Verhalten: Alle starten sie den Windows-Installer.
Dabei zeigt sich über Sysinternals Procmon eine Gemeinsamkeit im Startprozeß: Alle diese GPG-Programme kämmen die Registry nach Einträgen unter der Kennung "{000C101C-0000-0000-C000-000000000046}" - das ist die für den MSI-Server - durch. Danach folgt ein kurzes Übergeben desselben Scans an den SVCHost, dann folgt der Start des MS-Installers mit dem bekannten Unsinn in der bekannten Endlosschleife.
...Weiter geht's: Hab per Zufall entdeckt, daß der MSInstaller Logs im User-Temp-Verzeichnis hinterläßt.
Dort finde ich erstmal bestätigt, daß dieser Schweinehund auf magische Weise automatisch mitgestartet wird, wenn gewisse andere Programme gestartet werden - gleich in der ersten Log-Zeile:
=== Verbose logging started: 22.07.2012 05:09:31 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: D:\Werkzeug\System\Security\PGP\GPGtools.exe ===
Dann gehen die bodenlosen Frechheiten aber erst richtig los...
Obwohl auf meinem System die suizidöse Einstellung "AlwaysInstallElevated" NICHT gesetzt ist, ...
MSI (s) (AC:C0) [05:09:31:567]: Machine policy value 'AlwaysInstallElevated' is 0
...erlaubt sich dieser Installer dies dennoch...
Running product '{9A0ED01E-FD18-457A-AB9C-0835DCDB17BB}' with elevated privileges: Product is assigned.
...weil er festgestellt, daß ich das VORHER IRGEDNWANN mal mit Admin-Konto gerunned hatte...
Product {9A0ED01E-FD18-457A-AB9C-0835DCDB17BB} is admin assigned: LocalSystem owns the publish key.
Wenn ich das so in der Logdatei lese, rollen sich mir die Fußnägel hoch.
Ich weiß noch lange nicht, was ich im Detail davon zu halten habe, aber der erste Eindruck ist desaströs.
================
Also, meine Vermutung, wie das ganze zusammenhängt, geht derzeit in folgende Richtung:
Aus irgendeinem mir unerklärlichen Grund ist das GPG-Zeugs so programmiert, daß es generell bei jedem Start den MS-Installer mitstartet, der mal eben gucken soll, ob nicht ein Patch für das GPG verfügbar ist. Normalerweise isses nicht, so daß dieser MS-Installer unmittelbar wieder beendet wird und die Applikation normal startet, so daß man von dem Zeug unter normalen Bedingungen auch nichts mitkriegt.
(P.S.: Das hängt wohl damit zusammen, daß das GPG-GUI in VisualBasic programmiert ist - auch eine Microsoft-Suppe - und die VB Runtime benutzt, die sich ihrerseits in den Tiefen des Systems an undokumentierten Features vergreift einschließlich unerlaubten automatischen Installationsorgien...)
JETZT aber hat sich von dem MSVC-Zeug irgendwie irgendwas als benutzerspezifischer Nach-Konfigurationsschritt "registriert", und während das MSI-Zeug vom GPG treudoof mitgestartet wird, entdeckt es diesen Schrott und versucht, ihn auszuführen. Ich werde jetzt mal das Plattform-SDK wieder runterschmeißen und gegentesten, ob da was dran ist...
VORHER hatte ich allerdings nochmal testen wollen, ob mit dem Setzen von
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer:
isableUserInstallsdas Problem sofort abzustellen wäre. Bei der Gelegenheit entdecke ich zufällig, daß auf dem System
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer::EnableAdminTSRemote
gesetzt ist (jetzt war). Da hatte sich Microsoft was ganz tolles gedacht, um von einer Terminal-Sitzung aus in fremde Systeme eingreifen zu dürfen. Wobei zugegebenermaßen noch ein paar Voraussetzungen dazugehören (ein Admin-Konto bspw.). Mag ja eine begrenzt sinnvolle Idee gewesen sein, um DAU's vom Support helfen zu lassen - WENN denn das System ansonsten für illegale remote Sessions abgedichtet wäre. Was ich im allgemeinen hochgradig bezweifle. Jedenfalls halte ich sowas (Hintertürchen einrichten) generell für eine Frechheit. Ich gehe aber davon aus, daß von sowas auch nach mehreren Jahren Systemwartung noch etliche Einträge im System herumgeistern werden...
...Und "DisableUserInstalls" bringt gar nix. Jedenfalls nicht ohne Neustart (ist ein solcher eventuell notwenig?)
Beim Versuch des Neustarts werden mir neu verfügbare Updates vom Windows Update um die Ohren gehauen... Also ERSTMAL zwischendurch rüber ins Admin-Konto und dort die Updates angucken und gegebenenfalls einspielen...
Dabei wird jetzt genauso wie unter dem normalen Benutzerkonto diese Installation des PSDK gestartet... Die sagt mir nun, daß der User "..." (von dessen Konto ich eben rüber kam) "has previously initiated..." (eine Frechheit, so eine falsche Tatsachenbehauptung, gelle?!) "...an install for product 'Microsoft Platform SDK (R2) ()3790.2075). That user will need to run that install again..." (aha, da haben wir's erstmal offiziell, wo's herkommt) "...before they..." (Einzahl und Mehrzahl seien vollig egal in englandiges Sprach) "...can use that product..."
Eh - nicht mal Rechtschreibung beherrschen die bei MS... Kein Wunder, daß die Programme wie Kraut und Rüben funktionieren...
Das Update, welches da wartet, ist das Service Pack zur MS .Net Runtime. DAS werde ich jetzt NICHT installieren, weil das in der Vergangenheit AUCH schon IMMER Probleme bereitet hat (eine weitere Endlosschleife von ewiglich fehlschlagenden Installationsversuchen), die ich JETZT NICHT unter die ohnehin schon vorhandenen Fehler des MS-Installers mischen möchte...
Freude nach dem Neustart: Jetzt sagt mir auch der - immer noch - unter dem Benutzerkonto gestartete MSI-Schrott, daß der Admin eine Installation dieses PSDK-Schrotts gestartet hätte, welches er nicht mehr nutzen könne würde, bis er diese Installation nochmal ausgeführt hätte. Jetzt haben wir also eine sich gegenseitig befütternde Endlos-Schleife zum Quadrat. Eh: Die Programmierer, die sowas verbrechen, gehören doch auf der Stelle lobotomiert, gell?!
================
So, nach einer Entspannung von diesem versauten Rechtemißbrauch durch Microsoft-Produkte habe ich einfach mal dem "msiexec.exe" das Recht zum Ausführen durch Benutzer und System entzogen - so daß nur noch das Admin-Konto das Ding starten darf. Damit ist jetzt für den Moment erstmal Ruhe eingekehrt. Dafür noch zwei kleine Batchdateien vorbereitet, die analog zur Execution Policy dem msiexec die Rechte BEI BEDARF wiedergeben und ebenso schnell wieder entziehen können.
Eine RICHTIGE Lösung ist das jedoch nicht: Dazu wäre es notwendig, die tatsächliche Ursache der versaubeutelten Installation herauszukriegen. Da bin ich immer noch gespannt auf Ideen (und weiter selbst am suchen)...
Scheint ja im Moment echt tote Hose hier im Forum zu sein...
So... Jetzt wurden aber ganz andere Kräfte geweckt... Jetzt startet beim Login der "WGATray" (Windows will wohl jetzt, wo msiexec vom System nicht mehr ausgeführt werden kann, eine Systemänderung erkannt haben), wird allerdings sofort danach wieder beendet (nur der Process Explorer von Sysinternals verrät, daß da vor ein paar Sekunden was gelaufen war). Außerdem poppen zwischendurch ganz kurz mehrere Fensterchen auf - wohl weil derjenige, der - wie auch immer (ist ja streng geheim alias undokumentiert) - dieses msiexec krampfhaft zu starten versucht, diese Versuche natürlich noch lange nicht aufgegeben hat...
=== Verbose logging started: 22.07.2012 19:23:21 Build type: SHIP UNICODE 3.01.4001.5512 Calling process: C:\WINDOWS\Explorer.EXE ===
Nun ja: GPG ist offenbar nicht das einzige Programm, das irgendwie den MS-Installer automatisch auf irgendwelche Updates oder Nachinstallationsschritte abklopft...
Allerdings bleibt das jetzt zumindest nach wenigen Millisekunden hängen:
MSI (c) (A0:0C) [19:23:21:828]: Es konnte keine Verbindung mit dem Server hergestellt werden. Fehler: 0x80070005
Gut so für's erste...
==============
Fortsetzung auf ner alternativen Linie: Im Internet fand sich ein Hinweis auf ein gewisses "Fixit" von Microsoft (Fix problems with programs that can't be installed or uninstalled), welches nach vager, weitgefaßter Interpretation eventuell auch in der Lage sein können müßte, bei meinem Problem auszuhelfen (letztlich will ich ja von dem blöden Installer gar nichts mehr wissen).
Der Versuch, das betreffende Programm ("Microsoft-Installer-Fixit-portable.exe") zu starten, resultiert über die Zwischenstufe, mal wieder etwas bei mir eigentlich mit dem Tode bestraftes zu versuchen (Das EIGENTLICH Programm über ein extrem verteiltes und - natürlich, wer würde irgendwas anderes erwarten? - undokumentiertes, noch nicht mal wenigstens knapp angedeutetes (nur die Firewall läuft im Hintergrund Amok) Herunterladen von irgendwelchen nicht näher definierten weiteren Programmpaketen - wir erinnern uns bei sowas vage an das typische Verhalten von Viren und Trojanern, gell?! - im verbotenen Temp-Ordner abzulegen und dann dort im selben Zuge zur Ausführung bringen zu wollen, tsssss...), nachdem ich dieses zugelassen habe in der von Sarkasmus triefenden Meldung: 'Sie verfügen nicht über die erforderlichen Berechtigungen, um dieses Programm auszuführen.... Die Funktion "runas" wird von diesem Programm nicht unterstützt...'.
Klar: Ein fehlerhaft ausgewerteter Fehler in einem Programm, welches bei der Behebung eines fehlerhaft ausgewerteten Fehlers helfen sollen täte. Hatte ich was anderes erwartet? Nein, eigentlich nicht. Deshalb hatte ich diesen Versuch ja auch so lange hinausgezögert.
Wobei: Das Programm, was eigentlich ausgeführt werden soll, ist ja ein gänzlich anderes: Das kommt über insgesamt DREI Nachladestufen (Microsoft-Installer-Fixit-portable.exe -> MatsBoot.exe -> LaunchFixit.exe, wobei die Zwischenschritte mit den CAB-Dateien und deren an Umständlichkeit nicht mehr zu toppenden Entpackungen bereits weggelassen wurden) ins System (zwei davon hatte dieser "Fixit"-Witz immerhin zu nehmen geschafft).
Klar: Ein Programm, welches bei PROBLEMEN helfen soll, macht man bei Microsoft NATÜRLICH mindestens dermaßen künstlich aufgebauscht kompliziert, daß man zwingend einen bezahlten Service-Techniker von denen und eine Hotline zum lieben Gott persönlich benötigt, um überhaupt dieses Dingens in Benutzung nehmen zu können. Die wollen ja Geld sehen, kann man ja verstehen...
Sie HÄTTEN natürlich auch gleich das Zeug namens "LaunchFixit.exe", welches da auf der (für mich momentan scheinbar) letzten Stufe EIGENTLICH zur Ausführung gebracht werden sollte, samt seinen 20 Megabytes Daten in einem einfachen Archiv verpackt zur Verfügung stellen können, gell?! Wobei: Das HABEN die ja sogar: http://download.microsoft.com/downl...C-42D2-AC7F-8A6AD2920E6D/MatsOfflineSetup.cab
Aber indem ich das hier erwähne, begehe ich mit Sicherheit ein Urheber-Verbrechen, weshalb ich mit dem mindestens 1 Millionenfachen Strafmaß bedacht werden muß, welches man kassiert, wenn man Urheberverbrechen im industriellen Stil begeht... ...Sorry, ich schweife vom Thema ab...
...Ich hab jetzt einfach mal das "LaunchFixit.exe" direkt auszuführen versucht. Natürlich (ich hatte nicht wirklich was anderes erwartet) funktioniert es nicht ("Laufzeitfehler des Programms"). Beim näheren Untersuchen mit Procmon zeigt sich, daß dieses Ding genau dieselben Kapriolen schlägt wie der MS-Installer (dem er davon abhelfen sollte): Der unter dem Admin gestartete Prozeß startet seinerseits einen Prozeß unter dem System-Konto, der wiederum einen Prozeß unter dem Konto des aktuellen Desktop-Besitzers (also dem eingeschränkten Benutzer) aus einem temporären Verzeichnis heraus zu starten versucht - was selbstverständlich gar nichts anderes kann als nicht funktionieren.
Ich glaub, die haben die Trojaneritis bei Microsoft. Aber durchweg.
Irgendein Manager muß bei denen was falsch verstanden haben, daß die ihre Programmierer in den letzten Jahren dazu zwingen, solchen Schwachsinn zu fabrizieren. Weil: Ich kann mir nicht ausmalen, wie jemand von allein auf solche Ideen kommen sollte...
Wobei: So ganz klar ist das aus dem Procmon-Log auch wieder nicht: "Access Denied" tritt zwar an genau solchen Stellen auf, wo letztlich die "LaunchFixit.exe" unter dem Benutzerkonto mit Recht zum executen geöffnet werden soll, aber diese Aktion steht seltsamerweise in Verbindung mit Firewall-Aktionen, die im Gesamtlog keinen offensichtlichen Bezug zu den sonstigen Aktionen des Ursprungsprozesses haben...
Aber es scheint mir erstmal nicht sinnvoll, diese Schiene weiter zu verfolgen: Zuviel Aufwand!
==============
Ich glaube, ich komme der Sache langsam näher: Using Self-Healing to Your Advantage | eWall.org
Allerdings fehlt dort jede Erläuterung über die System-Mechanismen. Es wird alles anhand phänomenologischer Erscheinungen der Authoring-Software erklärt (schieb dies und das dort und dort hin)...
...Erstmal auf die längere Schiene geschoben: Erläuterungen zur Technik hinter der Fassade ist im ganzen Internet fast nicht zu finden, das bißchen (zum Beispiel Hinweise auf irgendwelche ominösen "advertising flags") hat bislang gar nichts gebracht (hab die zwar in den Windows-Installer-Hinterlassenschaften gefunden, aber konnte die Tips nicht nachvollziehen).
Beim Platform-SDK ist ja durchaus auch ein Satz MSI-Dokumentation dabei, habe ich gerade gesehen...
==============
Habe jetzt - nachdem alles andere versagt hatte - erstmal die Option probiert (einer der häufigsten Tips zu Problemen mit dem Installer hinsichtlich Endlosschleifen - ich bin da bei weitem nicht der einzige, aber die Erscheinungsformen sind doch arg vielfältig), das störenden Modul zu deinstallieren und dann nochmal neu zu installieren.
Da ich inzwischen ja ausreichend genau wußte, welche Erscheinungen so auftreten, konnte ich schnell und aussagekräftig testen:
Nach Deinstallation waren die parasitären Starts des Windows Installers beim Start zum Beispiel des GPG-Zeugs weg (fein!).
Nach Reinstallation waren sie wieder da.
Ach ja, übrigens: Diese hochgeistigen Microsoft-Install-Spezialisten haben doch glatt ein Office10-Verzeichnis kreieren lassen. Woher die die Weisheit nahmen, das Ding im Root-Verzeichnis meiner zweiten Festplatte anlegen zulassen, wird wohl auf ewig in den Annalen dieser Typen versteckt bleiben. Jeweils können die sich das dahin stecken!
Ich könnte natürlich auch nochmal einen krass härteren Weg gehen: Aus der Registry samt und sonders alles rausschmeißen, was irgendwie an dieses PSDK oder irgendwas damit zusammenhängendes erinnert. Allerdings tut es mir um die dafür zu verbratene Lebenszeit leid.
Ich nehm erstmal wieder die General-Abschaltung von msiexec...
...Neeee, ich mach das jetzt noch ganz anders: Ich lege jetzt einfach ein Archiv der installierten Dateien an, deinstalliere den Scheiß und kopiere anschließend die Dateien wieder zurück...
===============
Finally solved.
Die IDE meckerte noch zweimal von wegen, daß sie wieder mal "zur erstmaligen Benutzung initialisieren" müßte oder so ähnlich, aber dann war Ruhe im Karton und die Bibliotheken stehen ebenfalls alle zur Verfügung.
Amen!
(Hinterher fragt man sich immer wieder, warum man nicht gleich auf diese einfache Lösung gekommen ist: Die Ideen-Ansätze waren durchaus von Anfang an da, nur der Wille, etwas funktionsunfähiges unbedingt doch zur Funktion zu bringen, führte zeitweilig in die Irre...)
Zuletzt bearbeitet: