SharpDevelop & VS... selber Debugger?

Hi Leute,

kurze Frage: verwenden SharpDevelop und Visual Studio den selben Debugger?

Ich kämpfe immer noch mit BlueScreens. Sie tauchen auf, wenn ich Projekte im Debugger laufen lasse, die viele Threads erzeugen, die ihrerseits viel Speicher I/O machen und viel CPU Zeit beanspruchen. Die BSODs tauchen aber nur auf, wenn die Projekte im Debugger laufen. Ohne Debugger funktionieren die Projekte tadellos.

Die BSODs tauchen in beiden IDEs auf, sowohl in SharpDevelop als auch in VS. Daher vermute ich, dass der selbe Debugger verwendet wird.

Falls dem so ist, gibt es evtl. (freie) Alternativen, damit ich mal verifizieren kann, ob's tatsächlich am Debugger liegt?

Danke

Grüße,
Hendrik

WinDbg ist eine alternative, die du mal ausprobieren kannst. Das Handling allerdings ist nicht gerade optimal.

Oder falls möglich auf Mono laufen lassen und den Monodebugger nutzen.

Die Wahrscheinlichkeit das es aber am Debugger liegt ist meiner Erfahrung nach verschwindend gering. Eher komment die Unterschiede zwischen Debugger und Release durch das unterschiedliche Laufzeitverhalten zustande. Multithreaded Anwendungen können sich total unterschiedlich verhalten, grad wenn man net genau getestet hat und sich irgendwelche Race Conditions eingefangen hat.

Was für nen Bluescreen bekommst du denn? Aus den Dumps die man sich erzeugen lassen kann beim Bluescreen hat man übrigens auch noch die möglichkeit festzustellen was für nen Code den Bluescreen ausgelöst hat.

Naja, ich benutze für die Erstellung der Threads das Parallel-Framework von .NET 4.0. Somit müssten m.E. Race Conditions schonmal wegfallen, da die erstellten Threads alle unabhängig voneinander sind.

Es gibt außer der GUI keine gemeinsamen Resourcen unter den Threads. Und die GUI läuft prinzipbedingt ja schon ausschließlich in einem einzigen Thread. Außerdem greifen die Datenthreads ausschließlich aktualisierend, sprich schreibend auf die GUI zu (über Dispatcher). Race Conditions sind also, wenn sie nicht irgendwo im Framework selbst auftreten, eigentlich ausgeschlossen.

WinDbg hab ich bisher nur benutzt, um mir die Memory Dumps von den BSODs anzuschauen. Daraus ersichtlich ist nur, dass sie angeblich immer im Modul ntkrnlmp.exe auftreten und immer den Code 3B haben. Anbei ein Auszug aus dem Crash Dump des letzten BSOD:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\082010-58406-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*V:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`03062000 PsLoadedModuleList = 0xfffff800`0329fe50
Debug session time: Fri Aug 20 17:21:24.220 2010 (UTC + 2:00)
System Uptime: 0 days 0:08:18.327
Loading Kernel Symbols
...............................................................
................................................................
...........................................................
Loading User Symbols
Loading unloaded module list
......
\*******************************************************************************
\*                                                                             *
\*                        Bugcheck Analysis                                    *
\*                                                                             *
\*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff800030674e0, fffff8800bdbc540, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+c186 )

Followup: MachineOwner
---------

1: kd> !analyze -v
\*******************************************************************************
\*                                                                             *
\*                        Bugcheck Analysis                                    *
\*                                                                             *
\*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800030674e0, Address of the instruction which caused the bugcheck
Arg3: fffff8800bdbc540, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP: 
nt! ?? ::FNODOBFM::`string'+c186
fffff800`030674e0 8a01            mov     al,byte ptr [rcx]

CONTEXT:  fffff8800bdbc540 -- (.cxr 0xfffff8800bdbc540)
rax=000007ffffff0000 rbx=fffff8800bdbd030 rcx=000007ffffff0000
rdx=0000000000000000 rsi=0000000000000001 rdi=0000000000000000
rip=fffff800030674e0 rsp=fffff8800bdbcf10 rbp=0000000074b4ac00
 r8=0000000000000000  r9=0000000074b83528 r10=fffff8800bdbdba8
r11=0000000074b30000 r12=0000000074b74898 r13=fffff8800bdbd000
r14=fffff8800c034d10 r15=0000000074b83500
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
nt! ?? ::FNODOBFM::`string'+0xc186:
fffff800`030674e0 8a01            mov     al,byte ptr [rcx] ds:002b:000007ff`ffff0000=??
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  CaptureRequest

CURRENT_IRQL:  1

LAST_CONTROL_TRANSFER:  from fffff8000339f6ed to fffff800030674e0

STACK_TEXT:  
fffff880`0bdbcf10 fffff800`0339f6ed : fffff880`00000000 00000000`74b30000 fffff880`00000000 fffff880`00000000 : nt! ?? ::FNODOBFM::`string'+0xc186
fffff880`0bdbcfa0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PspGetSetContextInternal+0x481


FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+c186
fffff800`030674e0 8a01            mov     al,byte ptr [rcx]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+c186

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

STACK_COMMAND:  .cxr 0xfffff8800bdbc540 ; kb

FAILURE_BUCKET_ID:  X64_0x3B_nt!_??_::FNODOBFM::_string_+c186

BUCKET_ID:  X64_0x3B_nt!_??_::FNODOBFM::_string_+c186

Followup: MachineOwner
---------

1: kd> !thread
GetPointerFromAddress: unable to read from fffff8000330a000
THREAD fffffa8009e0fb60  Cid 1a6c.1a8c  Teb: 000000007ef37000 Win32Thread: fffff900c401d780 RUNNING on processor 1
Not impersonating
GetUlongFromAddress: unable to read from fffff80003248b74
Owning Process            fffffa800954c900       Image:         CaptureRequest
Attached Process          N/A            Image:         N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount      31943        
Context Switch Count      19188                 LargeStack
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x00000000684159c0
Stack Init fffff8800bdbddb0 Current fffff8800bdbc1d0
Base fffff8800bdbe000 Limit fffff8800bdb2000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0bdbbc78 fffff800`030d1ca9 : 00000000`0000003b 00000000`c0000005 fffff800`030674e0 fffff880`0bdbc540 : nt!KeBugCheckEx
fffff880`0bdbbc80 fffff800`030d15fc : fffffa80`09fe4370 00000000`00000002 00000000`00000000 fffffa80`09fe4370 : nt!KiBugCheckDispatch+0x69
fffff880`0bdbbdc0 fffff800`030f840d : fffff800`032e0ce4 fffff800`03219758 fffff800`03062000 fffff880`0bdbccd8 : nt!KiSystemServiceHandler+0x7c
fffff880`0bdbbe00 fffff800`030ffa90 : fffff800`032221a0 fffff880`0bdbbe78 fffff880`0bdbccd8 fffff800`03062000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`0bdbbe30 fffff800`0310c9ef : fffff880`0bdbccd8 fffff880`0bdbc540 fffff880`00000000 00000000`00000000 : nt!RtlDispatchException+0x410
fffff880`0bdbc510 fffff800`030d1d82 : fffff880`0bdbccd8 fffff880`0bdbd030 fffff880`0bdbcd80 00000000`00000001 : nt!KiDispatchException+0x16f
fffff880`0bdbcba0 fffff800`030d08fa : 00000000`00000000 fffff880`0bdbd030 fffff880`0bdbce00 fffff800`030d093d : nt!KiExceptionDispatch+0xc2
fffff880`0bdbcd80 fffff800`030674e0 : 00000000`00004204 00000000`00010206 fffff880`0bdbcf30 00000000`00000018 : nt!KiPageFault+0x23a (TrapFrame @ fffff880`0bdbcd80)
fffff880`0bdbcf10 fffff800`0339f6ed : fffff880`00000000 00000000`74b30000 fffff880`00000000 fffff880`00000000 : nt! ?? ::FNODOBFM::`string'+0xc186
fffff880`0bdbcfa0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PspGetSetContextInternal+0x481

Hallo 7.e.Q,

ich würde eher mal den PC als den Debugger wechseln...

Eine .NET Anwendung sollte IMHO eigentlich gar nicht in der Lage sein, einen BSOD zu verursachen.
Und dass es sich um einen derart hartnäckigen Bug im Debugger handelt, kann ich auch nicht wirklich glauben.

Vielleicht solltest du mal das os oder den pc wechseln.

Es kam neulich eine lücke raus, die sich auf eine racecondition im win32 createthread bezieht. Bluescreens kommen schließlich nur durch fehler im kernel zustande. Allerdings denke ich dass die wahrscheinlichkeit dafür gering ist.