locked
Bug in Windows 7 Cursor Handling, 32 x 32 x 8 Bit Format RRS feed

  • General discussion

  • I don't quite know where to report Windows bugs to Microsoft, so I'm putting this here...

    Today I got to the bottom of a problem some of my customers running Windows 7 have been having.

    By an oversight, a couple of cursor resources I had created in my Windows application were accidentally 32 x 32 x 8 bits, where my intent was to create them as 32 x 32 x 1 bit (as the rest of my cursors in the application are; 32 bit cursors are the newest technology, but I don't want 32 bits for what I'm doing, specifically).

    It turns out there's a bug in Windows 7 handling of 8 bit cursor resources/files, causing at best sluggish cursor performance, and at worst data corruption leading to application crashes.  I was able to work around the problem by using a different cursor format.

    In short:

    Setting a 32 x 32 x 8 bit cursor into Windows 7 via the LoadCursor() then SetCursor() functions in user32.dll causes data corruption and application crashes.

    The bug does not show up in Vista x64 nor Windows XP 32 bit, but it does appear to be a problem in Windows 7 for both 32 bit and x64.

    I have seen this bug manifest differently on systems equipped with nVidia and ATI cards.  Those with the nVidia cards usually crash the application while the latter seem just to yield sluggish mouse response.  I don't know if it's a bug in the WDDM or just that by chance these systems were organized differently.

    The good news is that this seems to be a relatively uncommon cursor format, though you may find it used in older 32 bit applications.  It could well be responsible for some application instability seen with Windows 7.

    Hope Microsoft sees this and gets the fix in quickly.

    -Noel
    Friday, December 4, 2009 3:00 AM