Hallo Eric,
another winedbg feature request:
When the starting application spawns off other processes and exec itself, with the other spawned processes still running, and one of these processes crashes, and winedbg is configured to work on the starting console, winedbg starts, loads all dll, but then exits immediate due to the missing console.
In this situation, winedbg should test if console access is still possible, and when not, it should start magically an xterm.
I still prefer to use the console for winedbg interaction, as scrolling is easier.
Thanks
When the starting application spawns off other processes and exec itself, with the other spawned processes still running, and one of these processes crashes, and winedbg is configured to work on the starting console, winedbg starts, loads all dll, but then exits immediate due to the missing console.
can you be a bit more precise in the description. there are two possible cases : A/ either winedbg (in fact the debugging state of the debuggee) is set so that the debugger will only debug the debuggee and not its child processes B/ or winedbg is set up to debug the debuggee and all its children
in case A, the situation you describe shouldn't be a problem, as the crash in the child should open another debugger with another console in case B, you may have problem because winedbg is likely not to like the second loading of a process (see my previous mail on winedbg). I'd rather see being a problem (perhaps because of overlapping DLLs...)
does the loading dll message appears in the console as the first debugger or another one ? (you can turn on an option in the console which keeps the console opened after the program - here the debugger - has terminated)
A+