4. Nicht abgefangene Ausnahme in Meiner.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.

Nicht abgefangene Ausnahme in Meiner.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.

  • T

    catch (CException***** e)

    0
  • E

    Ich hatte das IsBOF ja auch weggelassen. 🙂

    Ich habe das eher so als Überbleibsel an der Stelle - ohne gab es sonst auch nie Fehler... 🙄

    fReturn wird mit false initialisiert (Sorry, DAS hätte ich wirklich noch mitposten sollen.)

    Die MoveNext wird extrem häufig angesprungen und auch in 99% ohne Fehler.
    In der Funktion suche ich nämlich per ID nach einem Datensatz - das brauche ich ständig. 😃

    TheBigW schrieb:

    catch (CException***** e)

    Nein, sie wird ebenfalls nicht gefangen. 😕

    0
  • D

    Also wenn catch(...) nichts fängt würde es mich ja wundern, wenn irgendwas anderes dann was fangen würde...

    0
  • E

    Mich ja auch, aber ich hab ja schon gesagt, dass ich davon kaum Plan habe, also versuche ich es einfach mal. 🙂
    Wenn ich keine Ahnung habe, haben andere meistens erstmal Recht. 🤡

    Ich habe jetzt mal mitzählen lassen und die Traces angeschaut. Ich kann kein Schema erkennen, jedenfalls nichts, was mit der Anzahl der Aufrufe zu tun hat.
    Außer, dass die erste Ausnahme (die anderen habe ich noch nicht verglichen) immer bei Nr. 736 fliegt und das im Doppelpack.
    Aber seht selbst, ich habs mal hochgeladen: http://www.larsaf-iii.de/forum/trace.txt 🙂

    0
  • D

    Hm... Ist der Datensatz vielleicht korrupt?

    0
  • D

    Naja, auf jedenfall würde ich jetzt mal den MoveNext bei dem es das erste mal kracht (und den kennst du jetzt ja, wenn cih das richtig verstanden hab) einfach mal durchdebuggen. Dann hast du vielleicht nen Anhaltspunkt, woran es liegen könnte.

    0
  • E

    So, ich hab ihn da mal angehalten und kann leider nix böses erkennen:
    Es ist nicht BOF, nicht EOF, die Feldinhalte sehen heile aus.

    Gibt es andere Member von CRecordset, wo man drauf achten muss. 😕

    0
  • D

    In welcher Zeiler crasht er denn dann effektiv?

    0
  • E

    Soo, erstmal der Callstack:

    KERNEL32! 77e9bbf3()
MSVCRT! 78007108()
ODBCCR32! 1f8224af()
ODBCCR32! 1f824b50()
ODBCCR32! 1f82844f()
ODBC32! 01618cb8()
CRecordset::FetchData(unsigned short 1, long 1, unsigned long * 0x0012f5dc) line 3049 + 35 bytes
CRecordset::Move(long 1, unsigned short 1) line 1414 + 27 bytes
CRecordset::MoveNext() line 82 + 60 bytes
CBasisSetEx::Suche(long 0) line 82

    Das Suche ist die Funktion, deren Code ihr ja mittlerweile kennt. 🙂
    Der Rest ist MFC Code (von unten nach oben):

    _AFXDBCORE_INLINE void CRecordset::MoveNext()
	{ ASSERT(IsOpen()); Move(1, SQL_FETCH_NEXT); }

    [cpp]void CRecordset::Move(long nRows, WORD wFetchType)
    {
    ASSERT_VALID(this);
    ASSERT(m_hstmt != SQL_NULL_HSTMT);

    // First call - fields haven't been bound (m_nFieldsBound will change)
    if (m_nFieldsBound == 0)
    {
    InitRecord();
    ResetCursor();
    }

    if (m_nFieldsBound > 0)
    {
    // Reset field flags - mark all clean, all non-null
    memset(m_pbFieldFlags, 0, m_nFields);

    // Clear any edit mode that was set
    m_nEditMode = noMode;
    }

    // Check scrollability, EOF/BOF status
    CheckRowsetCurrencyStatus(wFetchType, nRows);

    RETCODE nRetCode;

    // Fetch the data, skipping deleted records if necessary
    if ((wFetchType == SQL_FETCH_FIRST ||
    wFetchType == SQL_FETCH_LAST ||
    wFetchType == SQL_FETCH_NEXT ||
    wFetchType == SQL_FETCH_PRIOR ||
    wFetchType == SQL_FETCH_RELATIVE) &&
    m_dwOptions & skipDeletedRecords)
    {
    SkipDeletedRecords(wFetchType, nRows, &m_dwRowsFetched, &nRetCode);
    }
    else
    // Fetch the data and check for errors
    nRetCode = FetchData(wFetchType, nRows, &m_dwRowsFetched); // <----

    // Set currency status and increment the record counters
    SetRowsetCurrencyStatus(nRetCode, wFetchType, nRows, m_dwRowsFetched);

    // Need to fixup bound fields in some cases
    if (m_nFields > 0 && !IsEOF() && !IsBOF() &&
    !(m_dwOptions & useMultiRowFetch))
    {
    Fixups();
    }
    }
    [/cpp]

    RETCODE CRecordset::FetchData(UWORD wFetchType, SDWORD nRow,
	DWORD* pdwRowsFetched)
{
	RETCODE nRetCode;

	if (m_nOpenType == forwardOnly && !(m_dwOptions & useExtendedFetch))
	{
		ASSERT(wFetchType == SQL_FETCH_NEXT);

		AFX_ODBC_CALL(::SQLFetch(m_hstmt));
		*pdwRowsFetched = 1;

		m_bDeleted = FALSE;
	}
	else
	{
		AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType,
			nRow, pdwRowsFetched, m_rgRowStatus)); // <------- (0x01653c98, 1, 1, 0x0012f5dc (1), 0x00774b00 (0))

		// Set deleted status
		m_bDeleted = GetRowStatus(1) == SQL_ROW_DELETED;
	}

	CheckRowsetError(nRetCode);

	return nRetCode;
}

    Dann kommt nur noch Assemblercode - der hilft uns nix, oder? 😕

    0
  • D

    Hab ich das richtig verstanden?

    Er crasht in der Zeile:

    AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType,
            nRow, pdwRowsFetched, m_rgRowStatus));

    ?

    0
  • E

    Ja, das ist die letzte lesbare Zeile.
    Wenn ich da F11 drücke, kracht es.

    0
  • ?

    habe NULL ahnung aber n versuch ist es ja wert

    mach doch in der DB "übersichtliche" einträge

    so 100 werte
    jetzt laufe wie gehabt alle durch

    wenn du einen bekommst schreibst du in einen logfile den datensatz
    und machst dann movenext

    eventl. immer die datei öffnen und gleich schliessen ( wegen crash )

    maybe hilft dir das weiter. wenn es immer der gleiche ist, dann den untersuchen.

    ka, ist verzwickt

    0
  • E

    Es ist leider nicht der gleiche. 😞

    Ich habe mit mal zusätzlich zum Zähler noch die Tabelle und die aktuelle ID ausgeben lassen. Hab das Trace wieder hochgeladen. http://www.larsaf-iii.de/forum/trace.txt

    An mehr Einzelheiten der Zeile komme ich da nicht dran, weil ich in einer Basisklase bin, wo wirklich blos das bekannt ist.

    0
  • D

    Sicher, dass du die neue Datei hochgeladen hast? Sieht für mich genau gleich aus wie die alte.

    0
  • E

    Ups, die neue hatte sich "verflogen". Jetzt passts aber. 🙂

    0
  • D

    Wow.
    Es wird mysteriös 😉

    Und genau deswegen tipp ich einfach darauf, dass du irgendwo anders nen Zeigerfehler hast 😉

    0
  • E

    Zeigerfehler? 😮
    Ahhh, geh weg mit dem bösen Wort... 🤡

    Im Ernst: So spontan fällt mir keine Stelle ein, wo ich da Zeiger verwende. Ich werde mal gucken, aber irgendwie fürchte ich, dass ich an der Sache noch lange knabbern werde. 😞

    0
  • D

    Das ist halt meine Erfahrung. Fast jedesmal, wenn ich so einen völlig unerklärlichen Fehler hatte, hat entweder ein Neustart, ein Rebuild All oder das Suchen nach Pointer-Problemen an anderer Stelle geholfen.

    0
  • E

    Neustart und RebuildAll fallen wohl raus, denn die Fehler habe ich schon ziemlich lange drin - so einige Monate bestimmt.
    Es funktioniert ja, also habe ich mich nur sporadisch darum gekümmert und bin daran gescheitert, dass kein catch reagiert.

    Ich habe eben mal "weiter oben" im Callstack geschaut - da ist kein offensichtlicher Zeiger zu finden. Das sind alles Codeschnipsel, die mehrfach im Programm sind und sonst keine Fehler bringen.

    Ich habe auch extra einen RebuildAll gemacht - das kommt bei der selben Zahl. 😞

    Und Zeigerfehler woanders suchen wird lustig... 😮
    Da kann ich nur hoffen, dass es weiterhin nicht schlimm ist und ich es irgendwann finde. 😞

    0
  • D

    Ich hatte mal was, wo mir n Zeiger ganz woanders was zerschoßen hat. Bis ich das gefunden hatte. urks.

    0
Anmelden zum Antworten