Debugging .NET 4 Applications
Windbg is a debugger people resort to, if things go wrong in production and it typically is used to analyze dumps. However using it isn't trivial and needs specialized training and lot of experience. I got initiated in using windbg after I had attended an advanced debugging training conducted by MS and it had covered lot of windbg usage scenarios.
VS 2008 offered some control on debugging a currently executing process and debug it by using the sos extension, that windbg uses for debugging .net managed code. However this was limited in its feature set. VS 2010 along with .net 4 makes this lot of windbg like and will mostly do away the need for using windbg in most scenarios.
A challenge in debugging production code is the size of dump files. They are huge and hence transferring them is mostly an issue. A new feature in .net 4 allows the profiler to attach to a running process, get access to memory data, help do the analysis and then detach, without having a need to take a memory dump.
While this is good, an issue with this is that since you would be profiling production process, it will cause the process to slow down. So use this feature sparingly.
Machines are dual core and above these days and more and more programs will start to do multi-core programming. .NET 4 itself adds support for Task parallel library, making multi-core programming easier. With VS 2008, one could do basic cross thread debugging. The debugger allowed you to figure out what thread is executing the current code and would also highlight when the execution would jump from one thread to other. Similar support is now possible for different cores and detailed reports on how cores were used during program execution can also be obtained.
Note that the debugging APIs have undergone significant changes. So you won't be able to debug .NET 4 code using VS 2008. There are a few other features as well, that might interest you. See the detailed article on this here.
VS 2008 offered some control on debugging a currently executing process and debug it by using the sos extension, that windbg uses for debugging .net managed code. However this was limited in its feature set. VS 2010 along with .net 4 makes this lot of windbg like and will mostly do away the need for using windbg in most scenarios.
A challenge in debugging production code is the size of dump files. They are huge and hence transferring them is mostly an issue. A new feature in .net 4 allows the profiler to attach to a running process, get access to memory data, help do the analysis and then detach, without having a need to take a memory dump.
While this is good, an issue with this is that since you would be profiling production process, it will cause the process to slow down. So use this feature sparingly.
Machines are dual core and above these days and more and more programs will start to do multi-core programming. .NET 4 itself adds support for Task parallel library, making multi-core programming easier. With VS 2008, one could do basic cross thread debugging. The debugger allowed you to figure out what thread is executing the current code and would also highlight when the execution would jump from one thread to other. Similar support is now possible for different cores and detailed reports on how cores were used during program execution can also be obtained.
Note that the debugging APIs have undergone significant changes. So you won't be able to debug .NET 4 code using VS 2008. There are a few other features as well, that might interest you. See the detailed article on this here.
