|
[Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Hallo,
seit Installation der aktuellen Windows-Updates (speziell unter Windows 10) kommt es zu Störungen bei der Ausführung von Programmen vieler Hersteller. Auch die Ausführung von meinem Programm ist betroffen. Es äußert sich in der Meldung „[Programmname] reagiert nicht mehr“ und der folgenden Anzeige: Zitat:
Zur Info: In den Suchergebnissen, sozialen Netzwerken und div. Foren gibt es aktuell (17.03.17) mehrere Lösungsansätze: 1) KB4013429 deinstallieren und Windows-Updates deaktivieren (Kontaktieren Sie hierzu Ihren Admin) 2) CompPkgSup.DLL von Dezember 2016 von einem nicht-aktualisierten PC kopieren und auf den betroffenen PCs unter C:\Windows\System32\CompPkgSup.DLL ersetzen. Benutzer berichten von Erfolg, jedoch ist generell davon abzuraten, da die anderen -aktualisierten- Systemdateien nicht garantiert mit dieser Version kompatibel sind und dies weitere Probleme hervorrufen kann. Zusätzlich muss die Datei auf Dateisystemebene Schreibzugriffen „Jeder“ (Jedem) verweigern. Auch davon wird generell von uns abgeraten.  https://www.reddit.com/r/sysadmin/co..._applications/„Workaround“: CompPkgSup.dll von anderem PC kopiert, der noch nicht aktualisiert ist Viele Programme haben aktuell das Problem: Windows Explorer, Windows Media Player, PowerDVD, … https://www.google.de/search?q=CompP...w=1733&bih=916Letztendlich hängt es irgendwie mit DVD/MPEG zusammen. An mehreren Stellen wird betont, dass Microsoft reparieren muss; Wir Programmierer können nix tun(?). https://answers.microsoft.com/en-us/...2-c95b4f40d978Der Fehler zeigt sich wie folgt im Ereignisprotokoll: Zitat:
Das Problem hängt explizit mit der Datei Windows-Systemdatei „CompPkgSup.DLL“ zusammen, und betrifft nicht ausschließlich aber speziell MPEG-Dateien. Die Suche bei Google nach „CompPkgSup.DLL“ in Verbindung mit neuen Ergebnissen innerhalb der letzten 24 Stunden zeigt zahlreiche betroffene Benutzer und Programme, auch den „Windows-Explorer“ und „Windows Media Player“, soweit z.B. CyberLink PowerDVD und „Notepad++“. Was kann man nun als Entwickler tun? In Delhi tritt der Fehler auch während dem Debuggen auf, in meinem Beispiel erzeuge ich Minibilder/Thumbnails von Mediendateien, hier konkret Videos: Zitat:
Delphi-Quellcode:
XtractImage ist zu dem Zeitpunkt scheinbar gültig ("Pointer($4A8D178) as IExtractImage"), BmpHandle ist 0, aber das wird glaube ich primär als Rückgabewert verwendet. Ab hier ist das eine reine API auf eine Windows-Funktion; ich kann mit dem Debugger nicht tiefer ins Detail gehen.
{ from ShlObjIdl.h }
IExtractImage = interface ['{BB2E617C-0920-11D1-9A0B-00C04FC2D6C1}'] function GetLocation(Buffer: PWideChar; BufferSize: DWORD; var Priority: DWORD; var Size: TSize; ColorDepth: DWORD; var Flags: DWORD): HResult; stdcall; function Extract(var BitmapHandle: HBITMAP): HResult; stdcall; end; XtractImage.Extract(BmpHandle); // verursacht den Absturzt // bzw. OleCheck(XtractImage.Extract(BmpHandle)); Was mich nun komplett irritiert ist die Tatsache, dass jede Exceptionbehandlung ins Leere läuft, und Windows mein Programm mit schön großer Fehlermeldung gegen die Wand fährt, anstatt den Fehler -wie vorgesehen- zu ignorieren:
Delphi-Quellcode:
Was kann ich gegen dieses "Programm funktioniert nicht mehr" tun? Warum kommt es? Ja es gab einen Fehler, aber warum greift meine Exception-Behandlung nicht?
try
XtractImage.Extract(BmpHandle); except end; Weitere Infos: -Delphi 2010 -Windows 10 Pro x64, alle Updates -Sophos AntiVirus
Delphi-Quellcode:
{-------------------------------------------------------------------------------
Unit Name: ShellObjHelper Author : hans gulo (HG) Purpose : Shell Object helper routines -------------------------------------------------------------------------------} unit ShellObjHelper; ... function ExtractImageGetFileThumbnail(const XtractImage: IExtractImage; ImgWidth, ImgHeight, ImgColorDepth: Integer; var Flags: DWORD; out RunnableTask: IRunnableTask; out Bmp: TBitmap): Boolean; var Size: TSize; Buf: array[0..MAX_PATH] of WideChar; BmpHandle: HBITMAP; Priority: DWORD; GetLocationRes: HRESULT; procedure FreeAndNilBitmap; begin {$IFNDEF DELPHI3} FreeAndNil(Bmp); {$ELSE} Bmp.Free; Bmp := nil; {$ENDIF} end; begin Result := False; RunnableTask := nil; Size.cx := ImgWidth; Size.cy := ImgHeight; Priority := IEIT_PRIORITY_NORMAL; Flags := Flags or IEIFLAG_ASYNC; GetLocationRes := XtractImage.GetLocation(Buf, sizeof(Buf), Priority, Size, ImgColorDepth, Flags); if (GetLocationRes = NOERROR) or (GetLocationRes = E_PENDING) then begin if GetLocationRes = E_PENDING then begin { if QI for IRunnableTask succeed, we can use RunnableTask interface pointer later to kill running extraction process. We could spawn a new thread here to extract image. } if S_OK <> XtractImage.QueryInterface(IRunnableTask, RunnableTask) then RunnableTask := nil; end; Bmp := TBitmap.Create; try try // !!!!! // Hier kommt nun die Windows-Fehlermeldung: // !!!!! OleCheck(XtractImage.Extract(BmpHandle)); // This could consume a long time. // If RunnableTask is available // then calling Kill() method // will immediately abort the process. except end; Bmp.Handle := BmpHandle; Result := True; except on E: EOleSysError do begin //------------- OutputDebugString(PChar(string(E.ClassName) + ': ' + E.Message)); //------------- FreeAndNilBitmap; Result := False; end; else begin FreeAndNilBitmap; raise; end; end; { try/except } end; end; |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Möglw. hilft wenn du SetErrorMode
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Delphi-Quellcode:
vor dem Application.Initialize an sich oder kurz vor dem Aufruf
SetErrorMode(SEM_FAILCRITICALERRORS)
bemühst. Ich bin mir allein nicht sicher ob das hilft in deinem Fall. Wenn es funktioniert hätte ein Blindes Huhn ein Korn gefunden. |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Danke für die Antwort.
Das hat keine Änderung gebracht. Wenn ich es übertreibe und z.B.
Delphi-Quellcode:
verwende, wird zwar keine Fehlermeldung angezeigt, allerdings geht das Programm kommentarlos zu (Prozess wird beendet), genau so wie wenn ich normalerweise in der Fehlermeldung den einzig verfügbaren Knopf klicke.
SetErrorMode(SEM_FAILCRITICALERRORS or SEM_NOALIGNMENTFAULTEXCEPT or SEM_NOGPFAULTERRORBOX or SEM_NOOPENFILEERRORBOX);
Es darf doch echt nicht sein, dass eine Drittanbieter- oder System-Komponente mit letztendlich irrelevanten Aufgaben das Worst-Case-Scenario auslöst (Programmabstürz) ohne Fehlerbehandlungsmöglichkeit(!) ... In meinem Beispiel ist es komplett egal wenn die Videoauflösung nicht ermittelt werden kann, bzw. das Minibild nicht gezeichnet wird, weil ich dann mit Standardwerten arbeite die zwar nicht so hübsch sind, aber es ist besser als eine krasse Fehlermeldung die alles in den Abgrund reißt... :| |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Zitat:
Und nein, das darf nicht sein. Aber wer Windows 10 benutzt ist halt ein Versuchskaninchen :) |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Leider keinen Windows 7 PC greifbar, ich muss mir kurzfristig was organisieren zum testen. Die Berichte im Internet beziehen sich (fast?) ausschließlich auf Windows 10.
|
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Wenn du 5 Sekunden keine Message los wirst sagt der WDM - Auf Wiedersehen. In deinem Fall kommt das WER und da ist alles schon lange vorbei. Warum Delphi die Exception sofern eine käme nicht unbedingt fängt, hinge vermutlich damit zusammen, dass es alle Stackframes usw. in der richtigen Reihenfolge benötigt. Ich denke aber es besteht nicht unbedingt ein Zusammenhang mit SEH.
Mir ist etwas schon öfters passiert bspw. mit Datenbank Client DLLs. |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Lass mich das gerade mal auseinanderfriemeln, ich glaube wir beiden sind da Unterschiedlich tief in der Materie drin :stupid:
WDM - Windows Driver Model - Windows Treiber Model - in diesem Fall die eingebundene DLL, die abstürzt wenn Sie auf MPEG oder was auch immer zugreift (normalerweise Geräte wie Graphikkarte --> DirectX, DirectShow, ...) WER - Windows Error Reporting - die Fehlerberichtserstattung von Windows, die letztendlich ungefragt mein Programm abschießt. (Naja, der Benutzer wird gefragt, aber ich als Programmierer würde an der Stelle halt gerne sagen: "Naja, dann halt nicht. Mach' ohne weiter...". SEH - ?? > 5 Sekunden keine Message los wirst Frage: An wen loswerden und welche Message konkret. Wäre es denkbar einen Thread zu schreiben, der egal wie im Hintergrund "Lebenszeichen" (also die Messages) sendet? Nenn' mir mal bitte Stichwörter, in welche Richtung ich suchen könnte; konkrete Beispiele wären natürlich genial. Wie hast du das mit deinen Datenbank-DLLs gelöst, außer ggf. durch eine neuere Version derselben? Danke nochmal. |
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Windows Desktop Manager
SEH - Structured Exception Handling. Aber ich habe deinen Fall zum Anlass genommen mir wieder mal jene Situation ins Gedächtnis zu rufen die solche Abstürze produzieren. Executables welche verschwinden. (ähnlich StackTrash, so ich mich recht erinnere, von Windows Internals). Ich hatte ein Phänomen ähnlich dem von dir beschrieben schon so lange nicht mehr, sodass sich kaum mehr erinnern kann wie ich es reproduzieren könnte. Das ginge so in die Richtung Unhandeld Exception Filter usw... Der sollte an sich alle unbehandelten SEH Exceptions fangen, sofern überhaupt noch eine kommt. Wie weit das in der VCL wiederum geht, muss ich mal gucken und was der Stand der Dinge im Moment am Windows 32 resp. 64 (sofern es Unterschiede gibt) überhaupt ist. Zitat:
|
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
Das Thema ist ein wenig seltsam :-D
Probiere, aber vergiss nicht ich hab das hurtig zusammengeflickt ohne so genau zu wissen was ich tue, einen Versuch mit einem Vectored Exception Handling. Zumal der installierte Handler die ganze Zeit den Prozess überlebt besser kurz vor deinem Aufruf welcher schief geht installieren und hernach gleich wieder deinstallieren. Je nachdem was dieser Handler als Rückgabewert gibt wird die Anwendung gezwungen eine Exception zu handeln, nicht oder weiter die Liste mit vektorbasieren Exeception Handlern abzuklappern.
Delphi-Quellcode:
Handler und Aufruf ...unit VEH; (* LONG CALLBACK VectoredHandler( _In_ PEXCEPTION_POINTERS ExceptionInfo ); PVOID WINAPI AddVectoredExceptionHandler( _In_ ULONG FirstHandler, _In_ PVECTORED_EXCEPTION_HANDLER VectoredHandler ); ULONG WINAPI RemoveVectoredContinueHandler( _In_ PVOID Handler ); ULONG WINAPI RemoveVectoredContinueHandler( _In_ PVOID Handler ); PVOID WINAPI AddVectoredContinueHandler( _In_ ULONG FirstHandler, _In_ PVECTORED_EXCEPTION_HANDLER VectoredHandler ); *) interface {$IFDEF WIN32} uses Windows; //Handler const CALL_FIRST = 1; const CALL_LAST = 0; const EXCEPTION_CONTINUE_EXECUTION = -1; const EXCEPTION_CONTINUE_SEARCH = 0; const EXCEPTION_EXECUTE_HANDLER = 1; type PVECTORED_EXCEPTION_HANDLER = function(const ExceptionInfo: _EXCEPTION_POINTERS): LongInt cdecl {$IFDEF WIN32} stdcall {$ENDIF}; // Installed after First Chance Exception function AddVectoredExceptionHandler(const FirstHandler: ULONG; const VectoredHandler: PVECTORED_EXCEPTION_HANDLER): PVOID; stdcall; function RemoveVectoredExceptionHandler(const VectoredHandlerHandle: PVOID): ULONG; stdcall; function AddVectoredContinueHandler (Const FirstHandler: ULONG; const VectoredHandler: PVECTORED_EXCEPTION_HANDLER): PVOID; stdcall; function RemoveVectoredContinueHandler (const VectoredHandlerHandle: PVOID) : ULONG; stdcall; implementation function AddVectoredExceptionHandler; external kernel32 name 'AddVectoredExceptionHandler' function RemoveVectoredExceptionHandler; external kernel32 name 'RemoveVectoredExceptionHandler' function AddVectoredContinueHandler; external kernel32 name 'AddVectoredContinueHandler' function RemoveVectoredContinueHandler; external kernel32 name 'RevomeVectoredContinueHandler' {$ENDIF} end.
Delphi-Quellcode:
Am Fehler wird es nichts ändern. Ich kann leider keine Windows Exception auslösen, so in der Richtung. Diese Exception Handling Routinen werden nach der First Chance Exception ausgeführt.uses VEH; function ForceExceptionHandling(const ExceptionInfo: TExceptionPointers): Longint; stdcall; begin // writeln('Vextored Exception Handler'); Result := EXCEPTION_CONTINUE_EXECUTION; //Result := EXCEPTION_EXECUTE_HANDLER; //Result := EXCEPTION_CONTINUE_SEARCH; end; procedure TForm1.bnVecotoredEhClick(Sender: TObject); var resf : Pointer; dummy : integer; begin try //try //writeln('Adding First Handler : EXCEPTION_CONTINUE_EXECUTION'); resf:=AddVectoredExceptionHandler(CALL_FIRST, ForceExceptionHandling); //writeln('Raising Exception'); raise EExternalException.Create('Howdy friends and neighbors'); dummy := 1; //except //end; finally //writeln('Removing First Handler : EXCEPTION_CONTINUE_EXECUTION'); RemoveVectoredExceptionHandler(resf); end; Wäre für Win32. EXCEPTION_CONTINUE_EXECUTION führt auf der Kommadozeile im Debugger zum Crash der Applikation. Im Fall von VCL was nicht viel sagt. EXCEPTION_EXECUTE_HANDLER könnte sein was du braucht. Das war bisher unproblematisch. Die ExceptionInfo im Handler ist gefüllt. Zitat:
|
AW: [Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 17:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz