Live Messenger Team: no connectivity popups!

March 26, 2009 at 10:44 am · Filed under Miscellaneous

I’ve been seeing lots of problems with Live Messenger connectivity lately.  I see this message a lot:

I don’t ever want Live Messenger to interrupt my work with that dialog.

If connectivity fails, use a notification balloon, or better yet, do nothing.  The red X on the tray icon already signifies trouble.  Let me drill down to find out more info.  This is a bad design decision.

If I dismiss the dialog, it will happen again.  And if I don’t dismiss it?  Well,

I left my machine from 9pm till 11am today and found my taskbar full:

Apparently Live Messenger thinks it is so important that I can’t connect that it needs to keep telling me.  Or at least telling the task bar.  This is a bug.

Live Messenger Team:  Please fix this.  I’m sure several of your myriad guidelines for Windows developers eschews any and all of this behavior. 

Tags: Bug, Live, LiveMessenger, Microsoft, Windows

Comments

Google Reader or TypePad getting confused?

March 7, 2008 at 2:56 pm · Filed under Web 2.0

Today while using Google Reader, the feeds for Recognizing Deven (http://munjal.typepad.com/recognizing_deven/index.rdf) and flow|state (http://miksovsky.blogs.com/flowstate/index.rdf) have both been serving the London Blog (which I have no interested in reading).

Is this a bug in Google Reader or TypePad?  Anyone else experiencing this?

And congratulations to Mr. Farrell for giving up the drink.

Tags: Bug, Google, GReader, Reader, TypePad

Comments

Dan’s Worst .NET Bug

February 17, 2008 at 8:16 pm · Filed under .NET

Last Thurday, Dan posted Worst .NET Bug I’ve Ever Seen.  This post was the result of a Digipede customer support incident resulting from this .NET behavior.  We had some trouble tracking it down.  The unexpected exceptions were bad enough — and the deceptive exception message text made it worse. 

He posted code to reproduce the problem on a single thread (a tight loop of open, write, close).  The actual code in question included no looping, but multiple threads following a fairly common pattern (i.e., open temp file, write, close, delete, rename).  The code was properly synchronized, but it still threw exceptions.  To keep this simple, I’ll stick with Dan’s simple version:

while (true) { 
   using (Stream sw = File.Open(strFileName, FileMode.Create)) { 
         using (BinaryWriter bw = new BinaryWriter(sw)) { 
            BinaryFormatter bf = new BinaryFormatter(); 
            bf.Serialize(bw.BaseStream, this); 
         } 
   } 
}

Loop this code on one or more threads and you may eventually get a System.IO.IOException.  I say may because I can’t reproduce it, but Dan can and so can one of our customers. 

Given many caveats (e.g., the paths are valid, the proper permissions exist, the file is not opened elsewhere, etc.), this code should never throw an exception.  The unmanaged resources should be released when the Stream.Dispose method is called.  The file should be closed.  The types of exceptions that our customer (and Dan) got all follow from the fact that sometimes the file isn’t closed.  Add a Thread.Sleep(1000) after the using block and the problem goes away.

So, is this a .NET bug or a Windows bug, or just expected behavior?

The first thing I did was take Dan’s simple loop and write it using the Windows Platform SDK (i.e., using the Windows API, not .NET).  I left out the delete/rename part of the pattern to make it like Dan’s tight loop.  The code looks like this:

while (true) { 
    HANDLE hFile = CreateFile(fileName, GENERIC_READ | GENERIC_WRITE, 
        0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);   

    if (hFile == INVALID_HANDLE_VALUE) { 
        printf("Could not open file (error %d)\n", GetLastError()); 
        break;; 
    }   

    byte buffer[1024]; 
    DWORD writtenBytes; 
    if (!WriteFile(hFile, buffer, sizeof(buffer), &writtenBytes, NULL)) { 
        printf("Could not write file (error %d)\n", GetLastError()); 
        break; 
    }   

    if (!CloseHandle(hFile)) { 
        printf("Could not close file (error %d)\n", GetLastError()); 
        break; 
    } 
}

This code works fine on Dan’s machine (i.e., never exits).  

Next steps

So, yes, this appears to be a problem in .NET.  My next steps are to . . .

1. Check the .NET versions / are they somehow different between our machines?
2. See if this is a known bug.  Connect.microsoft.com, here I come.
3. Question my assumptions.  

To this last point, does .NET (or Windows) not guarantee that a file is closed when the last handle is released?  If this is somehow true . . . how much code have you written that assumes that it does?  Me, a lot.  OK, not a huge amount, but enough that I’m really surprised this hasn’t come up before.

I’ll follow up on this post when I get to the bottom of it.  I also have some complaints about the content of some of the exceptions.  In the meantime, any reader want to try to reproduce this?

[tags].NET, .NET3.5, .NET2.0, CLR, BCL, Bug, Microsoft, Connect[/tags]

Tags: .NET, .NET2.0, .NET3.5, BCL, Bug, clr, Connect, Microsoft

Comments (3)