Share via

What is wrong with Whidbey?

  • Article

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.

Comments

  • Anonymous
    October 24, 2005
    As of the RC URL re-writting is completely broken and doesn't consistantly either leave relative (i.e. ~/) alone or remap them no matter what you set. (I and one other guy have reported this only to be blown off repeatedly)

    As of the RC a new bug has been introduced on the root page of an IIS site where the root page is of a inherited class that inherits from System.Web.UI.Page (i.e. a pageEx class that the page itself derives from). You'll get a crash that comes from the Render method. Thus you cannot use an inherited page as the root (default.aspx) page for a site unless the user types in www.darwinproductions.net/Default.aspx for example. (www.darwinproductions.net/ and www.darwinproductions.net in this example would crash with the error in the framework code)

    Neither of these have any satisfactory resolution on the feedback site. So yes, it has bugs and they're really breaking bugs as they stand unless they have actually been fixed from RC1 and final.
  • Anonymous
    October 24, 2005
    Hello James

    I was able to find the record of the issue that you mention.

    Does it work OK for you when you use RewritePath(path, false)? That is what we would expect from our testing.

    Thanks

    Mark
  • Anonymous
    October 26, 2006
    FYI all of this is still broken in the release of Vs.net 2005 and even in the beta of SP1 it still doesn't work. Relative pathing is still broken no matter how you set it so you have to use absolute pathing. I was able to get a hotifx for my first url writting bug I reported.... 10 months after I reported it and AFTER .net 2.0 was released.