Hallo (Eric),
is there another way of restarting a debugged process than to quit winedbg and restart the whole thing? All the dll need to get reparsed, all breakpoint need to get set up again.
it depends what you want to achieve (or avoid) : - as of today, loading of DLLs (and info parsing) is mandatory, and I don't see ways of removing it. One area of improvment would be to implement a quicker parsing engine (or delay some information loading until it's needed). gcc for example implements such a scheme: first it just parses for the name of symbols ; if needed, it then parses the full information to get the extra bits (type definition, function lines information...). that would need some extra work on winedbg to get this running. using gdb and the winedbg proxying stuff could help here. - from the "environment" point of view, what you can do is store all the needed commands to re-create your environment in a text file (setting breakpoints, setting displays..), and use the source command to reload this. we could rather easily automate the creation of such a file if needed.
from another perspective, winedbg does currently a lousy job at unloading DLL information when : - the process stops - and even worse, when a DLL gets unloaded (in other words, debug information is not attached internally to the module definition (as it should be), nor the process, but are global variables) unless this gets fixed, I'd recommend exiting and reentering the debugger for not running into the here above mentionned problems.
A+