locked
API Bug in Windows 7 RRS feed

  • General discussion

  • We've found a bug that was causing application corruption with our app, and it could be causing untold corruption with other apps as well.  It's something that worked in Windows Vista and XP, yet in Windows 7 it seems to have been broken, and is the nastiest kind of bug:  It causes corruption of memory elsewhere, which usually manifested as an application crash seconds or even minutes after the problem occurred.

    The problem is this:

    A pen with a pattern, created by loading a bitmap resource then calling the ExtCreatePen Win32 API call is created incorrectly.  When it is then used to draw things (e.g., a Rectangle) it will cause corruption all throughout the application in the form of memory and stack corruption.  This problem doesn't appear on every windows system, and may have to do with the video driver brand and/or whether any kind of remote access software is present (enabling RDP, for example, seems to stop the problem from happening).

    We worked on finding this problem for two solid weeks of 14 hour days before nailing it down.

    Specifically, this was the offending code (which worked great in XP and Vista):


    LOGBRUSH PenBrushDesc

    PenBrushDesc.lbStyle = BS_PATTERN;
    PenBrushDesc.lbColor = RGB(0,0,0);
    PenBrushDesc.lbHatch = (ULONG_PTR) LoadImage(DllModuleHandle, MAKEINTRESOURCE(CHECKERBOARD_BRUSH), IMAGE_BITMAP, 0, 0, LR_DEFAULTCOLOR);
    DragRectPen = ExtCreatePen(PS_GEOMETRIC | PS_SOLID, 1, &PenBrushDesc, 0, NULL);


    When the above pen was used to create a dotted line around a selection, the application would become hopelessly corrupted.

    The following code was used as a workaround for this problem, and works properly in Windows 7 (as well as earlier OSs):


    LOGBRUSH PenBrushDesc;
    DWORD DashArray[2] = {5, 7};

    PenBrushDesc.lbStyle = BS_SOLID;
    PenBrushDesc.lbColor = RGB(255,255,255);
    PenBrushDesc.lbHatch = 0;
    DragRectPen = ExtCreatePen(PS_GEOMETRIC | PS_USERSTYLE, 1, &PenBrushDesc, _countof(DashArray), DashArray);


    Microsoft, please make note of this.  Any application using this kind of logic to create a pen that draws a pattern could be destabilized by this bug.

    -Noel
    Saturday, December 12, 2009 7:38 AM

All replies

  • Thank you for reporting this problem, it was also causing me to tear my hair out when we started receiving bug reports from our customers about instability on Windows 7. The problem only occurs when Aero is enabled (which is probably why you noticed it go away over RDP) and only on some systems. It does not seem to be specific to a particular graphics card or driver.

    Our application uses a bitmap pen via ExtCreatePen as an important display feature. I've had to issue a patch to use a single-color pen when run on Windows 7.

    I'll report this directly to Microsoft support if this doesn't get addressed soon.
    Tuesday, February 23, 2010 4:51 PM
  • I just ran into this problem as well. Fortunately I was able to narrow down the source of the memory corruption to drawing lines with a pattern pen within a few hours.

    In my case the problem occurs when I am natively booted into Windows 7 64-bit on my Mac Pro (ATI Radeon HD 2600 XT, driver version 8.681.0.0) and Aero is enabled, but not when the same installation of Windows runs in a Parallels virtual machine on the same hardware, regardless of whether Aero is on.

    I spent a few hours trying to figure out where to report a Windows or GDI bug to Microsoft, without success, so I finally reported it as a Visual Studio bug (even though,
    in all likelihood, it is completely unrelated to Visual Studio):

    https://connect.microsoft.com/VisualStudio/feedback/details/538915/bs-pattern-pen-causes-memory-corruption-on-windows-7
    Friday, March 5, 2010 7:18 AM
  • For what it's worth I found that under VMware the bug would not occur, either.  That made it particularly frustrating early on.

    I had customers with real computers running both Windows 7 32 and 64 bit see it. 

    I have started to suspect perhaps it could be a problem in the WDDM template, and thus embodied in both ATI and nVidia drivers, but because the virtualization companies have had to write video drivers that fit into their software environments instead of hardware support perhaps they either found and corrected the bug or simply did not create a situation where it could manifest.

    Who'd have thought a virtual computer could be more stable than a real one.  :)

    -Noel
    Friday, March 5, 2010 2:48 PM
  • Thank you for reporting this bug.

    We find a bug fix:

    Just draw your lines into a path and then draw the path (stroke and fill it).

    In our program the following solution works:

     

     

    // Begin path:

    BeginPath (hDC);

     

    // Draw line into path:

    MoveToEx (hDC, nFromX, nFromY, NULL);

    LineTo (hDC, nToX, nToY);

     

    // End path and stroke and fill it:

    EndPath (hDC);

    StrokeAndFillPath (hDC);

     

    Monday, June 28, 2010 8:24 AM
  • New infos for this bug:

    If we draw into a memory DC (or path, see last message) we have no problems,

    if we draw into a device DC -> bang. we see no lines and memory gets corrupted.

     

    Friday, July 2, 2010 4:42 PM