Fremde Anwendung zerstört Thread

[EWeiss]

Ich starte zwei unterschiedliche Programme die beide meine DLL verwenden.
Die DLL befindet sich im jeweiligen Anwendungspfad und ist weder in Window noch darunter liegenden Pfade abgelegt.

Trotzdem zerstören diese meinen RenderThread wenn ein Programm geschlossen wird
und zwar immer den des noch offenen Programm (innerhalb der gerade verwendeten DLL)

Wie kann ich das verhindern?
Dürfte doch eigentlich nicht passieren.

Wie kann also eine andere Anwendung Terminate auslösen von gleicher aber unterschiedlich verwendeten DLL's in unterschiedlichen Pfaden.

Delphi-Quellcode:

      if WaitForSingleObject(VisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then
      begin
        DoOnVisTimer;
      end else
        Terminate;

gruss

[Uwe Raabe]

Wie äußert sich denn dieses Zerstören?

[Zacherl]

Ist der Timer ein Shared Object? Named Timer oder sowas?

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1232005)

Wie äußert sich denn dieses Zerstören?

In dem Terminate ausgeführt wird.

Da scheint ein problem mit WaitForSingleObject vorzuliegen.
Aber irgendwie unverständlich weil wie schon gesagt die DLL's in unterschiedlichen Pfaden liegen.

Andere Anwendungen sind davon nicht betroffen nur die welche die gleiche DLL verwenden.
Egal ob VB/Delphi oder sonst was.

gruss

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1232006)

Ist der Timer ein Shared Object? Named Timer oder sowas?

Delphi-Quellcode:

VisTimer := CreateWaitableTimer(nil, False, 'BassVisTimer');

Kann ich jetzt nicht beantworten ob er Shared ist.. sorry!
Deshalb etwas mehr code da kannst du vielleicht erkennen ob dies der Fall ist.

Delphi-Quellcode:

procedure TVisDataThread.Execute;
const
  _SECOND = 10000000;
var
  qwDueTime: Int64;
  liDueTime: _LARGE_INTEGER;
  ErrMsg: string;
begin

  if VisTimer = 0 then
    Exit;

  // Create a negative 64-bit integer that will be used to
  // signal the timer 1/4 seconds from now.
  qwDueTime := -1 * (_SECOND div 4);

  // Copy the relative time into a LARGE_INTEGER.
  liDueTime.LowPart := DWORD(qwDueTime and $FFFFFFFF);
  liDueTime.HighPart := longint(qwDueTime shr 32);
  if MySetWaitableTimer(VisTimer,                 // handle to a timer object
                        TLargeInteger(liDueTime), // when timer will become signaled
                        FDelayMS,                 // periodic timer interval
                        nil,                      // pointer to the completion routine
                        nil,                      // data passed to the completion routine
                        False {flag for resume state}) then
    // Following sentences are repeated every FDelayMS interval all the time from initial
    // start up to program end.
    repeat
      // We need to re-adjust timer interval according to the parameter "DelayMS" of vis plug-in.
      // (in case we exchange vis plug-ins)
      if FDelayMSChanged then
      begin
        FDelayMSChanged := False;
        CancelWaitableTimer(VisTimer);
        MySetWaitableTimer(VisTimer, TLargeInteger(liDueTime), FDelayMS, nil,
          nil, False);
      end;

      if WaitForSingleObject(VisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then
      begin
        DoOnVisTimer;
      end else
        Terminate;

      SuspendIfHalted;
    until Terminated
  else
  begin
    ErrMsg := SysErrorMessage(GetLastError);
    ShowErrorMsgBox(ErrMsg);
    Terminate;
  end;
end;

gruss

[himitsu]

Selbst wenn in beiden Programmen die selbe DLL geladen würde, wären diese grundsätzlich eigentlich erstmal vollkommen unabhängig voneinander, da jede DLL in den Prozesspeicher der zugehörigen EXE geladen werden. Und seit WinNT ist dierst Speicher vollständig getrennt.

Außer man bindet z.B. gemeinsame MMFs in die Prozessspeicher ein oder tauscht sonstwie "absichtlich" irgendwelche Handles, Speicher und sonstwelche externen Dinge.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1232011)

Selbst wenn in beiden Programmen die selbe DLL geladen würde, wären diese grundsätzlich eigentlich erstmal vollkommen unabhängig voneinander, da jede DLL in den Prozesspeicher der zugehörigen EXE geladen werden. Und seit WinNT ist dierst Speicher vollständig getrennt.

Außer man bindet z.B. gemeinsame MMFs in die Prozessspeicher ein oder tauscht sonstwie "absichtlich" irgendwelche Handles, Speicher und sonstwelche externen Dinge.

Ja!
Abgesehen ich würde diese in Windows/System32 oder darunter ablegen.
In dem Fall dürfte dann ausschließlich diese verwendet werden aber das ist ja nicht der Fall.

Problem könnte sein wenn diese in SysWow64 abgelegt wird.. aber hab da nix gefunden
Kann ich mir auch nicht vorstellen denn diese ist ja 32Bit.

Wie kann aber ein andere Anwendung auf den Thread einfluss nehmen bzw.. warum
tritt dann diese Abfrage nicht mehr ein?
sobald die andere geschlossen wird.

Delphi-Quellcode:

if WaitForSingleObject(VisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then

Ich kann es daran erkennen!
Verwendet die fremde Anwendung ein anderes Plugin Kind also anstatt Winamp > Sonique dann
läuft der Thread von Winamp als bsp. weiter.

gruss

[BUG]

Zitat:

Zitat von EWeiss (Beitrag 1232009)

Zitat:

Zitat von Zacherl (Beitrag 1232006)

Ist der Timer ein Shared Object? Named Timer oder sowas?

Delphi-Quellcode:

VisTimer := CreateWaitableTimer(nil, False, 'BassVisTimer');

Kann ich jetzt nicht beantworten ob er Shared ist.. sorry!

Zitat:

If the named timer object exists before the function call, the function returns a handle to the existing object and GetLastError returns ERROR_ALREADY_EXISTS.

[MSDN]

Vermutlich also ja: Alle deine Instanzen teilen sich einen Timer.
Was machst du mit dem Timer am Programmende? Ein CloseHandle sollte eigentlich keine Probleme machen; wenn du ihn deaktivierst, würde das deinen Fehler erklären.

Außerdem:

Zitat:

When an auto-reset timer is signaled, only one waiting thread becomes schedulable.

[Sample]

Damit könnte eventuell ein weiterer Fehler auftreten, indem ein Thread in das Timeout läuft, weil immer andere Threads signalisiert werden.

[EWeiss]

Zitat:

Vermutlich also ja: Alle deine Instanzen teilen sich einen Timer.
Was machst du mit dem Timer am Programmende? Ein CloseHandle sollte eigentlich keine Probleme machen; wenn du ihn deaktivierst, würde das deinen Fehler erklären.

Danke. Hab wieder was dazu gelernt ;)

Jo.. Ich schließe das Handle.

Delphi-Quellcode:

  if VisTimer <> 0 then
  begin
    if not Suspended then
      ThreadHalt;

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);
  end;

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1232020)

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

Das Handle wird bei Programmende ohnehin freigegeben, aber besser ist es, das selbst zu machen. Das Problem ist aber CancelWaitableTimer und nicht CloseHandle.

Denn:

Zitat:

Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The timer object is destroyed when its last handle has been closed.

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

Allerdings frage ich mich, ob es bei deinem Anwendungszweck überhaupt Sinn macht einen Namen für den Timer anzugeben. Warum machst du das? Denn viel sinnvoller wäre doch wohl mit unbenannten Timern unabhängig voneinander zu arbeiten, oder?