Macht Vista strengere Kontrolle der Schnittstelle Ids in DCOM Anrufe? (Der Stub erhielt falsche Daten)?

Question

Ich hoffe, dass jeder die Länge verzeihen, und narrative Weise dieser Frage. Ich beschloss, die Situation im Detail in meinem Blog zu beschreiben. Ich sah später Joel Einladung zu dieser Seite, und ich dachte, dass ich es hier einfügen würde, um zu sehen, ob jemand einen Einblick in die Situation hat.

Ich schrieb, und jetzt unterstützen, eine Anwendung, die von einem Visual Basic-Thick-Client besteht in C geschrieben spricht DCOM mittlere Ebene COM + Komponenten ++ ATL verwenden. Es läuft in allen acht unserer Büros. Jedes Büro beherbergt eine Back-End-Server, der die COM + Anwendung enthält (bestehend aus 18 getrennten Komponenten) und der SQLServer. Der SQL Server ist in der Regel auf dem gleichen Back-End-Server, muss aber nicht sein.

Wir wanderten vor kurzem des Back-End-Server in unserem größten Büro - in New York - von einem MSC-Cluster auf eine neue Maschine virtuellen auf VMWare-Technologie ESX gehostet. Da die Position der Anwendung COM + vom alten Server auf einen neuen mit einem anderen Namen umgezogen war, hatte ich alle Kunden umgeleitet werden, so dass sie die COM + -Anwendung auf den neuen Server aktiviert. Das Verfahren war ein alter Hut, wie ich im Wesentlichen die gleiche Sache für einige meiner kleineren Büros getan hatte, die durch ähnliche Infrastruktur-Upgrades gegangen war.

Alles schien Routine und am Montag Morgen das gesamte Büro - über 1.000 Windows XP Workstations - wurden auf den neuen Server ohne Zwischenfälle ausgeführt wird. Aber dann kam der Anruf von meinem Mobile Gruppe - dort einen Anwalt war Arbeit von zu Hause mit einer VPN-Verbindung, die einen seltsamen Fehler wurde immer nach auf den neuen Server umgeleitet werden:

Error on FillTreeView2 - The stub received bad data.

Hä? Ich hatte diese Fehlermeldung noch nie gesehen. War es der neue Server? Aber alle Arbeitsplätze im Büro arbeiten gut. Ich sagte der mobile Gruppe den Anwalt wieder auf die alten Sever zu wechseln (die immer noch waren), und der Fehler verschwunden. Was war der Unterschied? Es stellt sich heraus diesen Anwalt wurde mit Vista zu Hause.

Wir betreiben Vista nicht in allen unseren Büros, aber wir haben einige Anwälte, die Vista zu Hause laufen (sicherlich einige in meinem Büro in New York). Ich mache so gut und ich habe noch nie dieses Problem gesehen. Um zu bestätigen, dass es ein Problem war, feuerte ich meinen Vista Laptop auf, richtete sie auf den neuen Server, und bekam den gleichen Fehler. Ich zeigte es auf den alten Server zurück, und es funktionierte gut. Offensichtlich war es ein Problem mit Vista und die Komponenten auf den neuen Server - ein Problem, das nicht XP-Clients zu beeinflussen schien. Was könnte es sein?

Nächster Halt - die Anwendung Fehlerprotokoll auf meinem Laptop. Dies ergab weitere Informationen über den Fehler:

Source:        Microsoft-Windows-RPC-Events
Date:          9/2/2008 11:56:07 AM
Event ID:      10
Level:         Error
Computer:      DevLaptop
Description:   Application has failed to complete a COM call because an incorrect
interface ID was passed as a parameter.

The expected Interface ID was 00000555-0000-0010-8000-00aa006d2ea4, 
The Interface ID returned was 00000556-0000-0010-8000-00aa006d2ea4.

User Action - Contact the application vendor for updated version of the application.

Der Schnittstellen-IDs zur Verfügung gestellt, die Ahnung ich das Geheimnis zu lüften benötigt. Die "erwartete" Interface-ID identifiziert Cord-Schnittstelle des MDAC - speziell Version 2.1 diese Schnittstelle. Der „returned“ Schnittstelle entspricht eine spätere Version der Datensatzgruppe (Version 2.5, das am Ende der vtable von Version 2.1 durch die Einbeziehung eines zusätzlichen Eintrags unterscheidet - Methode Save)

.

Tatsächlich aussetzen meine Komponente Schnittstellen viele Methoden, die Recordset als Ausgabeparameter übergeben. So wurden sie plötzlich eine neuere Version von Cord-Rückkehr - mit einer anderen Schnittstelle ID? Es zeigte sich sicherlich der Fall zu sein. Und dann dachte ich, warum sollte es eine Rolle. Die V-Tabelle sieht gleich aus den Kunden des älteren Schnittstelle. Ich vermute sogar, dass, wenn wir über COM in-Prozess sprechen, und nicht DCOM, diese scheinbar harmlose Impedance Mismatch stillschweigend ignoriert worden wäre und würde keine Probleme verursacht hat.

Natürlich, wenn Prozess- und Maschinengrenzen ins Spiel kommen, gibt es einen Proxy und ein Stummel zwischen dem Client und dem Server. In diesem Fall war ich mit Typ-Bibliothek mit dem freien Gewinde Einweiser Marshalling. So gab es zwei Geheimnisse zu lösen:

Warum wurde ich eine andere Schnittstelle in den Ausgangsparametern von Methoden auf meinen neuen Server Rückkehr?

Warum haben diese Auswirkungen auf nur Vista-Clients?

Als mein Server software wurde bei jedem meiner acht Niederlassungen auf Servern gehostet, habe ich beschlossen, mein Zeigte Vista-Client auf alle von ihnen in Folge, um zu versuchen, um zu sehen, die mit Vista Probleme hatten und welche nicht. Illuminating-Test. Einige der älteren Servern arbeitete noch mit Vista, aber die neueren nicht. Obwohl einige der älteren Servern noch Windows 2000 ausgeführt wurden, während die neueren in 2003 waren, das schien nicht das Problem zu sein.

die Daten der Komponente DLLs Nach einem Vergleich zeigte sich, dass immer dann, wenn der Client-Server mit der Komponente DLLs zeigte vor 2003 datiert Vista war in Ordnung. Aber diejenigen, die nach 2003 DLLs mit Daten hatten, waren problematisch. Ob Sie es glauben oder auch nicht, es gab keine (oder zumindest nicht signifikant) Änderungen an dem Code auf den Server-Komponenten in vielen Jahren. Offenbar waren die unterschiedlichen Termine Neukompilierungen meiner Komponenten auf meiner Entwicklung Maschine (n) einfach durch. Und es zeigte sich, dass eine dieser Neukompilierungen 2003 geschehen ist.

Die Glühbirne ging weiter. Beim Passieren Record wieder vom Server zum Client, siehe meine ATL C ++ Komponenten an die Schnittstelle als _Recordset. Dieses Symbol stammt aus der Typenbibliothek in msado15.dll eingebettet. Das ist die Linie I ++ Code in der C hatte:

#import "c:\Program Files\Common Files\System\ADO\msado15.dll" no_namespace rename ( "EOF", "adoEOF" )

Lass dich nicht von den 15 in msdad15.dll getäuscht werden. Anscheinend DLL-Namen in der langen Reihe von MDAC-Versionen nicht geändert hat.

Wenn ich die Anwendung wieder in den Tag zusammengestellt, war die Version von MDAC 2.1. So _Recordset mit der 2.1-Schnittstelle ID kompilierte und das ist die Schnittstelle, die von den Servern mit diesen Komponenten zurückgegeben.

die Verwendung des All-Client die COM + -Anwendung-Proxy, der generiert wurde (ich glaube) zurück im Jahr 1999. Die Art Bibliothek, die meine Schnittstellen definiert enthält die Zeile:

importlib("msado21.tlb");

Das erklärt, warum sie die Version 2.1 von Recordset in meiner Methode der Ausgangsparameter erwarten. Offensichtlich war das Problem mit meinem 2003 recompile und der Tatsache, dass das _Recordset Symbol nicht mehr zu dieser Zeit entspricht Version 2.1. Tatsächlich entsprach _Recordset auf die Version 2.5 mit seiner eindeutigen Schnittstellen-ID. Die Lösung war für mich alle Verweise von _Recordset sich ändern in meinem C ++ Code Recordset21. Ich baute die Komponenten und entfalteten sie auf den neuen Server. Voila - die Kunden schien wieder glücklich

.

Abschließend gibt es zwei bohrenden Fragen, die für mich bleiben.

Warum hat die Proxy / Stub-Infrastruktur scheint anders mit Vista-Clients zu verhalten? Es scheint, dass Vista strengere Kontrollen der Schnittstelle ids machen wieder von Methodenparameter kommen als XP ist.

Wie soll ich 1999 codiert das anders zurück, so dass dies nicht passiert wäre? Schnittstellen sein sollte unveränderlich und wenn ich unter einer neueren Version von MDAC neu kompilierte, änderte ich versehentlich meine Schnittstelle, da die Methoden nun eine andere Cord-Schnittstelle als Ausgabeparameter zurückgegeben. Soweit ich weiß, zurück die Typenbibliothek dann keinen versionsspezifischen Symbol hat - das heißt, spätere Versionen der MDAC-Typbibliotheken definieren Recordset21, aber das Symbol nicht wieder in der 2.1-Typenbibliothek verfügbar

Answer 1

Wenn Microsoft die Sicherheit der Religion, DCOM (und die zugrunde liegende RPC) bekam bekam viel Aufmerksamkeit, und es gab auf jeden Fall Änderungen Sicherheitslücken zu schließen, die in strengen Serialisieren geführt. Ich bin überrascht Sie dies in Vista sehen, aber nicht in XP, aber es ist möglich, dass zusätzliche Kontrollen wurden für Vista hinzugefügt. Alternativ wurde es möglich die optionalen Strikt in XP obligatorisch in Vista.

Während ich weiß nicht genug über MDAC zu wissen, ob Sie dies hätte verhindert werden können, ich weiß, dass die Sicherheit einer der wenigen Bereiche, in denen Microsoft ziemlich bereit ist, die Abwärtskompatibilität zu opfern, so ist es möglich, dass Sie nicht haben konnte etwas getan, "besser" im Jahr 1999.