What is wrong with Whidbey?
The honest answer is “I don’t know”. I am fairly confident that the answer is “Not much” and smarter people than me are of the same opinion. We have good reason to think that it will be fine. A lot of our internal sites have been running in production with Beta code and more recently on the release candidates. Some early adopters have been doing the same. By the way, release candidate is a bit of an odd term. No-one actually expects that we will take a release candidate and send it live completely unaltered. At the very least, we will make sure that it doesn’t say release candidate anywhere. Maybe we should call them Kappa builds as they are a long way past Beta but not yet golden.
One thing that it is safe to say is that applications will still hit problems on Whidbey. Hopefully, this will rarely be because Whidbey is broken. The 2.0 framework is showing great stability but there is no framework so robust that a bad app can’t break it. Fortunately, there are many new features to make it easier to work out what went wrong than ever before.
First, there is the bad news. PSSCOR doesn’t work with the 2.0 framework, or at least, it doesn’t yet. If you are wondering what PSSCOR is, then you don’t read mvstanton’s blog (available at no extra charge from https://blogs.msdn.com/mvstanton). To save you trawling through the archives of this seriously good and hardcore blog, PSSCOR is SOS.DLL on steroids. It what we use internally for managed debugging. Another extension that we use a lot is SIEEXT and there is a public version of that call SIEEXTPUB.DLL. I haven’t noticed what the difference is yet (read “not much”). Anyway, I digress. For Whidbey, you will have to use the version of SOS.DLL that exactly matches the version of the runtime AND the runtime will need to be installed on your debugging system.
The good news is that you shouldn’t need to do this anything like as much. Whidbey has the managed debugging assistants. They are documented at https://msdn2.microsoft.com/en-us/library/d21c150d and there are some good explanations there. I would like to mention a couple that I think will become good friends.
GcUnmanagedToManaged can be a help in a tight spot. I have talked about GCholes before but I will recap very briefly. If you PInvoke to code and it writes asynchronously to a buffer that is not pinned then you will corrupt the managed heap. If it overruns or underruns the object then again, you will corrupt the managed heap (and would have corrupted an unmanaged heap as well). These errors are not much fun to debug because the AV normally happens long after the corruption on the next GC. To help us hunt then down, we use a tool called GCStress that forces a GC ludicrously often. It was developed as a way of stressing the GC and not a debug tool at all. The GcUnmanagedToManaged forces a GC at the end of calls to unmanaged code and so will make us crash a lot nearer the bad call. There is also a brother function that inserts a GC when leaving managed code but that probably won’t be as frequently used.
PInvokeLog logs Pinvoke calls to specified DLLs. That is a lot better than stepping through in the debugger to find out what got called.
RaceOnRCWCleanup is again fairly self describing. If you explicitly release COM components from managed code, you can easily get in to a race condition because your references are not reference counted. This turns on a check to spot if this happens. Can be a nasty one to troubleshoot otherwise since is it intermittent and nondeterministic.
PInvokeStackImbalance flags an error when a PInvoke would otherwise trash the stack. Trashed stacks are especially nasty because execution normally ends up in the middle of nowhere – and we normally haven’t got enough stack to work out how we got there.
You will have noticed that all of these related to interop with unmanaged code. The other assistants address the same area. There is a reason for this. They are normally the hardest problems to solve.
Signing out
Mark
P.S. Sorry about the long gap between posts. I have been busy at work and I have also been busy doing my homework on a creative writing course and building a remote control helicopter. “All work and no play makes Jack a dull boy” as Jack Torrance famously noted.