[Windows Update 03/2017 Problem] CompPkgSup.DLL schießt eigenes Programm ab

[berens]

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:

"Programm" funktioniert nicht mehr, es wird nach einer Lösung für das Problem gesucht [Durchlaufender Balken] - - -
Das Programm wird aufgrund eines Problems nicht richtig ausgeführt. Das Programm wird geschlossen und Sie werden benachrichtigt, wenn eine Lösung verfügbar ist.

Erste Recherchen haben ergeben, dass dies kein eigentliches Problem von meinem Programm ist, sondern ein Problem verursacht durch die Medien-Komponenten von Windows, die wir für die Wiedergabe von Videos [zwangsläufig] verwenden [müssen].

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=916

Letztendlich 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-c95b4f40d978



Der Fehler zeigt sich wie folgt im Ereignisprotokoll:

Zitat:

Fehlerbucket 108798616406, Typ 1

Ereignisname: APPCRASH

Antwort: Nicht verfügbar

CAB-Datei-ID: 0



Problemsignatur:

P1: Programm.exe

P2: 0.0.0.0

P3: 58cbc003

P4: CompPkgSup.DLL

P5: 10.0.14393.953

P6: 58ba5a1f

P7: c0000005

P8: 0000346b

P9:

P10:



Angefügte Dateien:

\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER1 DB9.tmp.WERInternalMetadata.xml



Diese Dateien befinden sich möglicherweise hier:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive \AppCrash_Planer.exe_63d47c1dfd94df8be758496664da2 08c7e217f25_ac402c4f_21144575



Analysesymbol:

Es wird erneut nach einer Lösung gesucht: 0

Berichts-ID: 454271e6-5b02-4cda-b56b-72fcf29174e7

Berichtstatus: 1

Bucket mit Hash: d310656fb3f0f08c78308020e24f49af

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:

:0f05346b ; C:\Windows\SysWOW64\CompPkgSup.DLL
:0f05417a ; C:\Windows\SysWOW64\CompPkgSup.DLL
:0f0518e6 ; C:\Windows\SysWOW64\CompPkgSup.DLL
:0f053aa3 CompPkgSup.AreDvdCodecsEnabled + 0x73
:0f04e07c
:0f04d7a9
:10956fea ; C:\Windows\SysWOW64\msmpeg2vdec.dll
:1094103e ; C:\Windows\SysWOW64\msmpeg2vdec.dll
:10940f72 ; C:\Windows\SysWOW64\msmpeg2vdec.dll
:758ac90b ; C:\WINDOWS\SysWOW64\combase.dll
:758b6dfa ; C:\WINDOWS\SysWOW64\combase.dll
:758acef2 ; C:\WINDOWS\SysWOW64\combase.dll
:758b1575 ; C:\WINDOWS\SysWOW64\combase.dll
:758b1640 ; C:\WINDOWS\SysWOW64\combase.dll
:758b16d7 ; C:\WINDOWS\SysWOW64\combase.dll
:758b18f7 ; C:\WINDOWS\SysWOW64\combase.dll
:758b6ddb ; C:\WINDOWS\SysWOW64\combase.dll
:758b2e7d ; C:\WINDOWS\SysWOW64\combase.dll
:758b6de2 ; C:\WINDOWS\SysWOW64\combase.dll
:758f77a0 ; C:\WINDOWS\SysWOW64\combase.dll
:758f6ba2 ; C:\WINDOWS\SysWOW64\combase.dll
:758f8209 combase.CoCreateInstance + 0xa9
:105588a4 ; C:\Windows\SysWOW64\mfds.dll
:10558602 ; C:\Windows\SysWOW64\mfds.dll
:1055757d ; C:\Windows\SysWOW64\mfds.dll
:1055db22 ; C:\Windows\SysWOW64\mfds.dll
:1056a2d3 ; C:\Windows\SysWOW64\mfds.dll
:1056caaf ; C:\Windows\SysWOW64\mfds.dll
:10577b56 ; C:\Windows\SysWOW64\mfds.dll
:105455b3 ; C:\Windows\SysWOW64\mfds.dll
:105468bc ; C:\Windows\SysWOW64\mfds.dll
:1054a943 ; C:\Windows\SysWOW64\mfds.dll
:051a9b1c ; C:\WINDOWS\SysWOW64\RTWorkQ.DLL
:051a932a ; C:\WINDOWS\SysWOW64\RTWorkQ.DLL
:76f27c43 ;
:76f26b56 ;
:765d62c4 KERNEL32.BaseThreadInitThunk + 0x24
:76f50fd9 ;
:76f50fa4 ;

In meinem konkreten Fall konnte ich den Fehler soweit zurückverfolgen:

Delphi-Quellcode:

  { 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));

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.

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:

  try
    XtractImage.Extract(BmpHandle);
  except end;

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?


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;

[MichaelT]

Möglw. hilft wenn du SetErrorMode

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

SetErrorMode(SEM_FAILCRITICALERRORS) vor dem Application.Initialize an sich oder kurz vor dem Aufruf

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.

[berens]

Danke für die Antwort.

Das hat keine Änderung gebracht.

Wenn ich es übertreibe und z.B.
  SetErrorMode(SEM_FAILCRITICALERRORS or SEM_NOALIGNMENTFAULTEXCEPT or SEM_NOGPFAULTERRORBOX or SEM_NOOPENFILEERRORBOX); 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.

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...

[a.def]

Zitat:

Es darf doch echt nicht sein, dass eine Drittanbieter- oder System-Komponente mit letztendlich irrelevanten Aufgaben das Worst-Case-Scenario auslöst

Bekommst du den Fehler denn auch mit einem Windows was NICHT Windows 10 ist?

Und nein, das darf nicht sein. Aber wer Windows 10 benutzt ist halt ein Versuchskaninchen

[berens]

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.

[MichaelT]

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.

[berens]

Lass mich das gerade mal auseinanderfriemeln, ich glaube wir beiden sind da Unterschiedlich tief in der Materie drin

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.

[MichaelT]

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 von berens:

Lass mich das gerade mal auseinanderfriemeln, ich glaube wir beiden sind da Unterschiedlich tief in der Materie drin

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.

[MichaelT]

Das Thema ist ein wenig seltsam

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:

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.

Handler und Aufruf ...

Delphi-Quellcode:

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;

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.

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 von berens:

Danke nochmal.

[arnof]

hier gibt den FIX:

http://www.pc-magazin.de/news/window...g-3197629.html