I have heard of the BSoD – what’s a WSoD?

If you have used the Windows Forms designer in Visual Studio 2005 enough, chances are you may have occasionally seen a white error screen instead of the design time form. This screen, fondly referred to as WSoD in our team, shows up when error(s) are encountered in the process of loading the designer.  Now, if you have used Visual Studio 2002/2003, you may recollect that in the face of errors, the designer would usually continue the load and quietly display the errors in the tasklist. That was much less intrusive and did not require the developer to drop whatever they were doing and fix the errors. Why then did we take this seemingly retrograde step back into the Windows 95 era?

There is a very good reason for that. If an error is encountered while loading the designer and you ignore it and make modifications to the design time form, there is inevitably one result - data loss. This is because the next time the designer flushes, it will wipe InitializeComponent() clean and serialize out code for the current state of components in the designer (this is how the designer always works). If there were lines of code in there that it failed to parse during the load, at this point they will be lost. This could mean property sets or even whole components 'disappear' from the designer.

It is to prevent this inadvertant data loss that we introduced the WSoD in VS 2005. The WSoD makes it very obvious to the user that there were errors, and does not allow modifications to be made to the designer till they are resolved. Now, unlike its blue counterpart, the WSoD actually contains information useful to the user. It shows a list of errors that were encountered along with stack traces and very often, the line of code in InitializeComponent() that is responsible for each error. Equipped with this information, the developer should be able to open the code behind file (which is now thankfully in a separate partial class, distinct from user code) and fix up the lines that caused the problem.

Now, clearly, not everyone is a huge fan of this idea. Developers don't like being blocked from making progress this way. For example, let's say you have a DataGridView and some other controls on your form referencing a DataSet in the project. If you delete the DataSet when you have the form designer window open, you will likely see a WSoD. This can be frustrating - why wasn't VS clever enough to auto-correct the problem for me?

Well, the problem is: what is the right solution?

Should it delete all the controls referencing the dataset automatically? What if the developer wanted them to remain there so they could set them up with a new dataset?

Should it keep the controls, but ignore the error and continue to load? Well, if the developer misses the warnings in the task list, all of a sudden, they might end up with controls in a bad state and lose some data.

So you see, there is no good 'automagic' solution. We thought it best to leave the developer in control of the situation and decide the best way to fix the issue. Essentially, we weighed user-friendlyness with data loss and ruled in favor of preventing data loss as much as possible. I don't know about you, but I would prefer to spend a few minutes fixing stuff up rather than inadvertantly losing hours of hard work with the next flush.

P.S.> If you have never heard of the BSoD (I am sure there are plenty of you that haven't :-)), here is a good description.

Comments (10)
  1. AndrewSeven says:

    I have seen the white 😉

    Having the event wire-ups dissapear from InitializeComponent() is a very tricky problem to find and fix. Things build and run, but buttons don’t do anything. Looking at the code view, the missing wire-ups are in a collapsed region.

    It might seem odd, but maybe the choice should be to comment out the code instead of deleting it (And thus uncomment code before inserting a duplicate :S which is probably brutal ).

    Losing the wireups can be hard to spot, but the problem is how to be sure that you add them all back…unless they are there commented out.

    I prefer the obvious failure that stops me rather than silent failure that could slip by unoticed.

  2. Shawn Burke says:

    Probably worth some definitions here for those that don’t have their MS-Glossary handy.

    BSoD: Blue Screen of Death

    WSoD: White Screen of Darn

    We didn’t think "death" was the right metaphor since in many cases it’s like any other error message. But it’s never what you want to see. Darn!

  3. franco rainusso says:

    i ate a whole bunch of chinzaminos

  4. Christopher says:

    [quote]We didn’t think "death" was the right metaphor since in many cases it’s like any other error message. But it’s never what you want to see. Darn![/quote]

    I think the "darn" here is more appropriate because there isn’t a "death" occuring like what happens with the BSoD (system crash).  The WSoD is more of a annoyance than a critical problem.

  5. Ivar says:

    I get WSoD with the following message "Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information." followed by a list of exceptions (no stacj trace. I do not understand what causes it. I did find a reference to a possible VS hotfix (?) and I also found a reference to removing indexing on project folders. It did help the first time, but now the problem is back and does not disappear. How can I proceed? How can I retrieve LoaderExceptions?

  6. Berke Sokhan says:

    We get the same problem frequently, but the messages were generally related with our 3rd party components’ licences.licx file. It seems like VS 2005 can’t load this license file appropriately or in time, because we didn’t write any code at that time only drag and drop. How can it be explained other than a bug?

  7. rprabhu says:

    One way of getting more information when you see a WSoD (and the information provided there isn’t sufficient) is to attach a debugger (maybe another instance of VS 2005) to Visual Studio (devenv.exe), run through the problem scenario and see what exceptions get thrown.

    If you suspect you found a bug in VS 2005 or have any suggestion/comment, please log it through http://lab.msdn.microsoft.com/productfeedback/. This is the ideal way to submit feedback, since both you and the product team can track it through resolution.

  8. Thinh says:

    No, I have been heard of the BSoD alot but WSoD is never.

    Sometimes when I install alot of software for my Palm, I have been saw a WSoD similar when windows error but WSoD not provide any reason.

  9. I’ve seen it many times in the past, now it has a name

Comments are closed.

Skip to main content