✔ Exception bei "Socket als Listener registrieren"

[deepthroat]

Hi.

Wie komme ich denn an die Debug-Builds der Bibliotheken ( das wäre dann MSCRTd?) ?

Die sind doch beim VS dabei (bzw. beim Windows SDK falls du eins extra installiert hast).

Du mußt nur gegen die richtige Library linken.

Und du solltest natürlich die .pdb vom Microsoft Symbolserver einbinden. (Debugging-> Symbols : Symbolserver anhaken und am besten ein Cache Verzeichnis dafür einrichten).

hmm, leider kann ich nirgendwo eine Aktivierung hierfür finden (bspw. gibt es bei mir in "C++ Exceptions" nur "_com_error", "ATL::CATLException", "CException", "std:exception" und "void" - bei VS2010 V10.0.40219.1 SP1Rel) .....

Alle diese Einstellungen betreffen First-Chance Exceptions (der Debugger stoppt sofort die Ausführung sobald eine dieser Ausnahmen geworfen wird, nicht erst wenn's irgendwo knallt). Hake die C/C++ Ausnahmen an und die Win32 Ausnahmen.

Gruß

 

[vfl_freak]

Moin deepthroat,

Die sind doch beim VS dabei (bzw. beim Windows SDK falls du eins extra installiert hast).
Du mußt nur gegen die richtige Library linken.

das war eigentlich meine Frage, welches denn (dafür) die richtigen sind, aber Du meinst vermutlich, dass von den verwendeten LIBs jeweils die 'd'-Version zu nehmen sei, richtig?

Und du solltest natürlich die .pdb vom Microsoft Symbolserver einbinden. (Debugging-> Symbols : Symbolserver anhaken und am besten ein Cache Verzeichnis dafür einrichten).
Alle diese Einstellungen betreffen First-Chance Exceptions (der Debugger stoppt sofort die Ausführung sobald eine dieser Ausnahmen geworfen wird, nicht erst wenn's irgendwo knallt). Hake die C/C++ Ausnahmen an und die Win32 Ausnahmen.

Ok, hab's hinbekommen - Junge, Junge, was wird der Aufruf dadurch langsam ... liegt aber vlt. auch an meinem RemoteDebuggen

Habe nun die angehängte Meldung bekommen ... muss ich das jetzt etwa so deuten, das die LIB "kernel32.dll" nicht gefunden wird ****
Sie liegt bei mir zum einen in "c:\WINDOWS\system32" und dann unter "c:\WINDOWS\ServicePackFiles\i386" .....

Dann ist mir jetzt gerade noch unterschiedliche Einträge in den Projekteingeschaften ("Linker/Eingabe/zusätzliche Abhängigkeiten") zw. meinen alten VS6 und dem aktuellen VS2010 aufgefallen :
VS6 - Debug :
Nafxcwd.lib Libcmtd.lib ws2_32.lib
VS6 - Release :
ws2_32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

VS2010 - Debug :
Nafxcwd.lib Libcmtd.lib ws2_32.lib
VS2010 - Release :
Nafxcw.lib Libcmt.lib ws2_32.lib

Sollte ich die "kernel32" deshalb hinzufügen?
IMHO ist dabei ja die Reihenfolge nicht ganz unerheblich, oder ?

Kannst Du mir dazu 'nen Tipp geben ?

Danke und Gruß
Klaus

EDIT: habe gerade mal die "kernel 32" eingetragen und dann gedebuggt - aber die Meldung kommt trotzdem :-(

 

[deepthroat]

Moin.

das war eigentlich meine Frage, welches denn (dafür) die richtigen sind, aber Du meinst vermutlich, dass von den verwendeten LIBs jeweils die 'd'-Version zu nehmen sei, richtig?

Ja.

Habe nun die angehängte Meldung bekommen ... muss ich das jetzt etwa so deuten, das die LIB "kernel32.dll" nicht gefunden wird ****

Nein. Die Exception tritt in der kernel32.dll auf. (und wird dann offenbar behandelt). Wenn du auf "Unterbrechen" klickst, sollte zumindest der Stacktrace angezeigt werden. In welcher kernel32 Funktion tritt der Fehler denn auf?

Wie gesagt, es ist vermutlich ein roter Hering.

Sollte ich die "kernel32" deshalb hinzufügen?
IMHO ist dabei ja die Reihenfolge nicht ganz unerheblich, oder ?

Die kernel32 ist eigentlich immer implizit dabei. Die Reihenfolge ist fast immer unwichtig, außer man nutzt so verquere Sachen wie du...

Gruß

 

[vfl_freak]

Moin,

Nein. Die Exception tritt in der kernel32.dll auf. (und wird dann offenbar behandelt). Wenn du auf "Unterbrechen" klickst, sollte zumindest der Stacktrace angezeigt werden. In welcher kernel32 Funktion tritt der Fehler denn auf?
Wie gesagt, es ist vermutlich ein roter Hering.

'nen reinen Stacktrace bekomme ich iwie nicht, aber im im Anhang die Aufrufliste des toten Fisches - hoffe, er/sie stinkt nicht

Die kernel32 ist eigentlich immer implizit dabei. Die Reihenfolge ist fast immer unwichtig, außer man nutzt so verquere Sachen wie du...

;-]

Gruß
Klaus

EDIT:
hier noch schnell die beiden dissassemblierten Stellen zu 'kernel32.dll' und die Stelle an der die o. g. Meldung hochkommt:

_BaseThreadStart@8:
7C80B6DC  push        10h  
7C80B6DE  push        7C80B720h  
7C80B6E3  call        __SEH_prolog (7C8024D6h)  
7C80B6E8  and         dword ptr [ebp-4],0  
7C80B6EC  mov         eax,dword ptr fs:[00000018h]  
7C80B6F2  mov         dword ptr [ebp-20h],eax  
7C80B6F5  cmp         dword ptr [eax+10h],1E00h  
7C80B6FC  jne         _BaseThreadStart@8+31h (7C80B70Dh)  
7C80B6FE  cmp         byte ptr [_BaseRunningInServerProcess (7C885008h)],0  
7C80B705  jne         _BaseThreadStart@8+31h (7C80B70Dh)  
7C80B707  call        dword ptr [__imp__CsrNewThread@0 (7C8012F4h)]  
7C80B70D  push        dword ptr [ebp+0Ch]  
7C80B710  call        dword ptr [ebp+8]  
### Cursor  ==> 7C80B713  push        eax  
7C80B714  call        _ExitThread@4 (7C80C0E8h)  
7C80B719  nop  
7C80B71A  nop  
7C80B71B  nop  
7C80B71C  nop  
7C80B71D  nop  
7C80B71E  nop  
7C80B71F  nop  
7C80B720  db          ffh  
7C80B721  db          ffh  
7C80B722  db          ffh

	// Socket als Listener registrieren
// ###################################################################################	
// Hier die nicht abgefangene Ausnahme in #GSWorkerServer.exe: 0x00000002: (kein Name)
// ###################################################################################	
	result = listen( s, SOMAXCONN );
00459885  mov         esi,esp  
00459887  push        7FFFFFFFh  
0045988C  mov         eax,dword ptr [ebp-18h]  
0045988F  push        eax  
00459890  call        dword ptr [__imp__listen@8 (947CD4h)]  
### Cursor  ==> 00459896  cmp         esi,esp  
00459898  call        std::_Tree_const_iterator<std::_Tree_val<std::_Tmap_traits<char *,CAlarmDatenBlockText *,std::less<char *>,std::allocator<std::pair<char * const,CAlarmDatenBlockText *> >,0> > >::operator--+123h (436263h)  
0045989D  mov         dword ptr [ebp-29Ch],eax

 

[deepthroat]

Hi.

'nen reinen Stacktrace bekomme ich iwie nicht, aber im im Anhang die Aufrufliste des toten Fisches - hoffe, er/sie stinkt nicht

Eigentlich meinte ich wirklich "rot" und nicht tot (https://de.wikipedia.org/wiki/Roter_Hering).

Die Disassemblate sagen nicht viel aus, nur das da eine Exception geschmissen wird und der Aufruf der listen Funktion.

Die Exception wird anscheinend aus NdrSendReceive ausgelöst. Da müßte man dann genauer hinschauen. Der Aufwand wird sich vermutlich nicht lohnen, da es mit dem späteren Absturz vermutlich nichts zu tun hat.

Gruß

 

[vfl_freak]

Moin,

Eigentlich meinte ich wirklich "rot" und nicht tot (https://de.wikipedia.org/wiki/Roter_Hering).

verstehe ... sieht ja lecker aus

Die Disassemblate sagen nicht viel aus, nur das da eine Exception geschmissen wird und der Aufruf der listen Funktion.
Die Exception wird anscheinend aus NdrSendReceive ausgelöst. Da müßte man dann genauer hinschauen. Der Aufwand wird sich vermutlich nicht lohnen, da es mit dem späteren Absturz vermutlich nichts zu tun hat.

Ja, wir haben hier jetzt auch erst mal beschlossen, das Ganze erstmal auf Eis zu legen (was sich ja bei Fischen anbietet ), zumal ich ja, wie gesagt, keinen Socket-Error bekomme und das Programm augenscheinlich normal weiterläuft. Dieses Problem besteht auch schon seit vor meiner Zeit (> 5 Jahre) und hat wohl nichts mit unseren aktuellen Problemen (gelegentliches Hochlaufen von Socketverbindungen oder auch Spontan-Abstürzen zu tun).

Aber Danke für Deine Mühe !
Gruß
Klaus