ExitInstance() liefert nicht den gewünschten wert zurück

Martin Richter

Hmmm. Für exit macht mich das aber sehr stutzig.
Hast Du mal den exit Code gedebuggt?

chermanns

Hallo,

In der "crtexe.c" kommen die richtigen Werte an (Das meintest Du doch, oder?).
exit(mainret);
enthält meine Werte. Aber auf den Rechnern, auf denen ich debugen kann bekomme ich ja auch den richtigen errorlevel zurück.
Problem sind die Rechner mit den redistributable packages und da kann ich nicht debugen. Aber wenn es damit diesbezüglich Probleme geben sollt hätte ich doch was im Netz gefunden.

Ich benutze die VS 2005 standard edition und auf den "anderen" Rechner das redistributable package 8.0.56336.

Hast du eine Idee?

Grüsse Carsten

Martin Richter

Exit benutzt direkt die entsprechende Funktion um die Applikation zu beenden.
Mir ist kein Fehler bekannt in dieser Richtung, dass sich hier eine CRT anders verhält...

chermanns

Habe noch auf zwei Rechnern mit Windows 7 und redistributable packages (ohne Entwicklungsumgebung) getestet. Auf den Rechnern bekomme ich den Rückgabewert den ich erwarte zurück.
Mit dem gleichen redistributable package auf den XP Rechnern installiert (zuvor alle anderen entfernt). Denoch bekomme ich eine 0 statt meinem Fehlercode.

Dazu fällt mit nichts mehr ein.

Hat jemand einen Idee was das sein kann?

Grüsse Carsten

Martin Richter

Kannst Du Dein Projekt auch statisch Linken? Was passiert dann?

chermanns

Das geht leider nicht, es ist ziemlich gross und beinhaltet dlls von anderen Leuten und besteht zudem aus recht vielen dlls die alle statisch gelinkt sind.
Ich schaue mir grade ob es einen Unterschied bei dem Beenden der Applikation hinsichtlich Threads gibt. Dazu benutze ich im ersten Schuss:
HANDLE hTaskSnap = CreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 );
um mir die Anzahl der Threads ausgeben zu lassen

int threadCounter = 0;

int threadCounterID = 0;
  {

    HANDLE  hThreadSnap = CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, 0 );

    THREADENTRY32 te32; 
    te32.dwSize = sizeof(THREADENTRY32 ); 
    int ret = Thread32First( hThreadSnap, &te32 );
    while (ret == TRUE){
      if (te32.th32OwnerProcessID == GetCurrentProcessId() ){
        threadCounter ++;
      } 
      if (te32.th32ThreadID == 0 ){
        threadCounterID++;
      }

      ret = Thread32Next( hThreadSnap, &te32 );
    }   DASTRACE(TRACE_LEVEL_INFO, _T( "th32OwnerProcessID:%i" ),threadCounter );
    DASTRACE(TRACE_LEVEL_INFO, _T( "th32ThreadID:%i" ),threadCounterID );

  }

dabei erhalte ich folgene Ausgabe, die mir nicht klar ist:

Auf den Systemen die sich richtig verhalten:
th32OwnerProcessID:4
th32ThreadID:2

bzw Windows 7:
th32OwnerProcessID:6
th32ThreadID:2

Auf den Systemen die sich falsch verhalten:
th32OwnerProcessID:4
th32ThreadID:1

Beschreibung zu th32ThreadID:
The thread identifier, compatible with the thread identifier returned by the CreateProcess function.

Da stosse ich an meine Grenzen was das bedeutet, hast du einen Tip?

chermanns

jubel!!
ich habe die Ursache gefunden.
Die Applikation ist etwas grösser. sie besteht aus der *.exe plus ca 20 DLLSs die von mir kommen plus ca 15 DLLs die von verschiedenen Zulieferen kommen.

In einer der zugelieferten DLLs hat sich etwas geändert und das hat meinen Returncode überschrieben.
Ich weiss nicht wie aber ich erhalte mit einer älteren Version der DLL den richtigen Returncode.

Mit der "fehlerhaften" DLL sehe ich, das aus der WinMain mit meinem Fehlercode (5) herauskomme, die Applikation aber mit 0 beendet wird.

Wenn mir das jemand erklären kann wäre ich dankbar!

Ausgabe Debugfenster:
'App.exe': Unloaded 'C:\WINDOWS\system32\comdlg32.dll'
'App.exe': Unloaded 'C:\WINDOWS\system32\winspool.drv'
The thread 'Win32 Thread' (0x8e0) has exited with code 5 (0x5).
The thread 'Win32 Thread' (0x9c8) has exited with code 5 (0x5).
The thread 'Win32 Thread' (0xbc8) has exited with code 5 (0x5).
The program '[2644] App.exe: Native' has exited with code 0 (0x0).

Grüsse Carsten

Martin Richter

Kann es sein, dass die andere DLL Deinen Prozess vorher mit ExitProcess beendet, bevor dein exit zuschlägt?

Setz mal einen Breakponint drauf.

chermanns

Beim Debugen sieht ja alles gut aus. ExitInstance() wird durchlaufen, danach sehe ich das noch einige Destruktoren von Singeltons durchlaufen werden.
bei einem BreckDann Raus aus der WinMain() sehe ich in der den mainret = meinen Exitcode (5).

/*
             * Note that if the exe is managed app, we don't really need to
             * call exit or _c_exit. .cctor should be able to take care of
             * this.
             */
            if ( !managedapp )
                exit(mainret);

danach halt die Ausgabe

The thread 'Win32 Thread' (0xd34) has exited with code 5 (0x5).
The thread 'Win32 Thread' (0x9f4) has exited with code 5 (0x5).
The thread 'Win32 Thread' (0x734) has exited with code 5 (0x5).
The program '[2356] App.exe: Native' has exited with code 0 (0x0).

Meitest du das oder habe ich dich falsch verstanden?
Die veursachende DLL wird dynamisch von einer andern DLL geladen, die auch zugeliefert wird (zumindest zeigt mir der depedency walker das so an).

Mir ist nicht klar was passiert, ob in der verursachenden DLL ein exit(0) aufgerufen wird oder ein ExitInstanze().

Kann ich (ausser den entsprechenden Entwickler zu benachrichtigen) etwas tun um das fehlerhafte Verhalten zu beseitigen (mir ist nichts bekannt, dass heisst aber nichts )?

Grüsse Carsten

Martin Richter

Du kannst doch auch einen Breakpoint auf Funktionen im OS setzen. Hier wäre ExitProcess oder ExitThread der Ansatz...

Evtl. kommt die DLL beim Uninit mir irgendwas nicht klar und terminiert seinerseits den Prozess...

Bist Du denn soweit vorgedrungen beim Debuggen in exit, dass Du wirklich sehen kannst das ExitProcess aufgerufen wird?

chermanns

Hallo Martin,

ich habe mit dem Entwickler gesprochen, der die "problematische" DLL läde.
Er sagte mir, dass er schon Probleme hatte und er früher innerhalb seiner DLL die problematisch DLL lädt und entlädt, dies (entladen ) nun aber nicht mehr macht (sich aber nun darum kümmert das es klappt).

Mein Statmente ist:
Ich bin zur Zusammenarbeit bereit bin aber nicht für alles verantwortlich was n Zulieferer bereitstellen, zumal der Integrationstest nicht bei uns stattfindet.

Ich bin dankbar für dieses Forum, die Hilfe die es beinhaltet und die offenen Ohren für die Probleme.

Grüsse Carsten