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

[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