[Bug 10522] New: endless WM_PAINT loop bug (update regions, queue paint count)

Summary: endless WM_PAINT loop bug (update regions, queue paint count) Product: Wine Version: CVS/GIT Platform: PC URL: http://www.microsoft.com/whdc/devtools/debugging/install x86.mspx OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-user AssignedTo: wine-bugs@winehq.org ReportedBy: focht@gmx.net

Created an attachment (id=9265) --> (http://bugs.winehq.org/attachment.cgi?id=9265) trace with WINEDEBUG=+tid,+message,+win,+server

Hello,

I've seen this bug a while ago in other apps but ignored it because it was not easily to reproduce. Well until recently when I tested some stuff with windbg from "Debugging Tools for Windows" (Microsoft). I used debugging tools version 6.8.4.0 and recent GIT (wine-0.9.49-302-g58b85bb).

Immediately when a child window was opened using toolbar (register, locals, .. whatever), windbg would become unresponsive, eating most CPU.

Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation. Though "MDI emulation" is more obvious, it actually shows the endless refreshing (window caption).

Attached is WINEDEBUG=+tid,+message,+win,+server log. Additionally I added a trace message which prints the current queue paint count (when incremented or fetched) which makes some things easier to spot. Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d".

The window hierarchy is as follows:

--- snip --- *root*=0x10020 Shell_TrayWnd=0x10022 WinDbgFrameClass=0x10024 DockClass=0x10026 ToolbarWindow32=0x10028 msctls_statusbar32=0x1002a tooltips_class32=0x1002e WinBaseClass=0x10030 ToolbarWindow32=0x10032 SysListView32=0x10034 SysHeader32=0x10036 RichEdit20W=0x10038 --- snip ---

After the child windows are created the queue paint count never drops to zero, resulting in endless WM_PAINT processing. Maybe some update (region) code path missed or flags problem? I played a bit with ignoring null region updates and it seemed to help a bit (preventing endless WM_PAINT loop) though other stuff wasn't drawn properly then.

Regards

-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

Show replies by date

wine-bugs＠winehq.org

3 Jun 3 Jun

6:06 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #1 from Austin English austinenglish@gmail.com 2008-06-03 13:06:10 --- Is this still an issue in 1.0-rc3?

-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

wine-bugs＠winehq.org

10 Jun 10 Jun

9:54 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #2 from Anastasius Focht focht@gmx.net 2008-06-10 04:54:01 --- Hello,

--- quote --- Is this still an issue in 1.0-rc3? --- quote ---

Sure.

Regards

wine-bugs＠winehq.org

22 Jul 22 Jul

6:28 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #3 from Anastasius Focht focht@gmx.net 2008-07-22 01:28:20 --- Hello,

Visual Studio .NET 2005 (http://appdb.winehq.org/objectManager.php?sClass=version&iId=4494) has a similar issue. In the "welcome"/"start page" there is an area/control "Visual Studio Headlines" being constantly redrawn, eating 50-100% of one CPU.

+tid,+msg,+win,+server between successive RedrawWindow calls (repeats forever):

--- snip --- .. 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10114, flags=00000005, region={{0,0;204,66}} ) 0009: redraw_window() = 0 0009:trace:win:release_dc 0x10114 0x30c 0009: set_caret_info( flags=00000006, handle=0x10114, x=0, y=0, hide=-1, state=1 ) 0009: set_caret_info() = ACCESS_DENIED { full_handle=(nil), old_rect={0,0;0,0}, old_hide=1, old_state=1 } 0009: get_update_region( window=0x10114, from_child=(nil), flags=00000023 ) 0009: get_update_region() = 0 { child=0x10114, flags=00000002, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip 0xbb0c, flags 00010080 0009:trace:win:GetDCEx found valid 0x12ecb0 dce [0x10114], flags 00000002 0009: get_visible_region( window=0x10114, flags=00000082 ) 0009: get_visible_region() = 0 { top_win=0x1002c, top_rect={280,108;1526,798}, win_rect={332,718;536,784}, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx (0x10114,0xbb0c,0x10080): returning 0x30c 0009:trace:win:GetWindowRect hwnd 0x10114 ((332,718)-(536,784)) 0009:trace:win:release_dc 0x10114 0x30c 0009: get_message( flags=00000000, get_win=(nil), get_first=00000000, get_last=ffffffff, hw_id=00000000, wake_mask=00000040, changed_mask=000004ff ) 0009: get_message() = 0 { win=0x10114, type=6, msg=0000000f, wparam=0, lparam=0, info=0, x=0, y=0, time=0000587e, hw_id=00000000, active_hooks=80000000, total=0, data={} } 0009:trace:msg:peek_message got type 6 msg f (WM_PAINT) hwnd 0x10114 wp 0 lp 0 0009: get_message( flags=00000001, get_win=(nil), get_first=00000000, get_last=ffffffff, hw_id=00000000, wake_mask=00000040, changed_mask=000004ff ) 0009: get_message() = 0 { win=0x10114, type=6, msg=0000000f, wparam=0, lparam=0, info=0, x=0, y=0, time=0000587f, hw_id=00000000, active_hooks=80000000, total=0, data={} } 0009:trace:msg:peek_message got type 6 msg f (WM_PAINT) hwnd 0x10114 wp 0 lp 0 0009: set_caret_info( flags=00000006, handle=0x10114, x=0, y=0, hide=1, state=0 ) 0009: set_caret_info() = ACCESS_DENIED { full_handle=(nil), old_rect={0,0;0,0}, old_hide=1, old_state=1 } 0009: get_update_region( window=0x10114, from_child=(nil), flags=0000002f ) 0009: get_update_region() = 0 { child=0x10114, flags=00000004, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip 0xbb18, flags 00010080 0009:trace:win:GetDCEx found valid 0x12ecb0 dce [0x10114], flags 00000002 0009: get_visible_region( window=0x10114, flags=00000082 ) 0009: get_visible_region() = 0 { top_win=0x1002c, top_rect={280,108;1526,798}, win_rect={332,718;536,784}, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx (0x10114,0xbb18,0x10080): returning 0x30c 0009:trace:win:BeginPaint hdc = 0x30c box = ((0,0)-(204,59)), fErase = 0 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip (nil), flags 00000003 0009:trace:win:GetDCEx found valid 0x12f978 dce [0x10114], flags 00000003 0009:trace:win:GetDCEx (0x10114,(nil),0x3): returning 0x384 0009:trace:win:release_dc 0x10114 0x384 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE .. --- snip ---

When the start page is closed, the problem goes away.

Regards

wine-bugs＠winehq.org

11:08 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #4 from Alexandre Julliard julliard@winehq.org 2008-07-22 06:08:55 --- (In reply to comment #3)

...
0009:trace:win:GetDCEx (0x10114,0xbb18,0x10080): returning 0x30c

0009:trace:win:BeginPaint hdc = 0x30c box = ((0,0)-(204,59)), fErase = 0 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip (nil), flags 00000003 0009:trace:win:GetDCEx found valid 0x12f978 dce [0x10114], flags 00000003 0009:trace:win:GetDCEx (0x10114,(nil),0x3): returning 0x384 0009:trace:win:release_dc 0x10114 0x384 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE

Looks like the window is invalidated again after being painted, so it's normal that it would loop forever. You should try to find out where that RedrawWindow call comes from.

wine-bugs＠winehq.org

9:55 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #5 from Anastasius Focht focht@gmx.net 2008-07-22 16:55:29 --- Created an attachment (id=14991) --> (http://bugs.winehq.org/attachment.cgi?id=14991) Recorded call sequences from window proc (expected behaviour)

Hello,

there seem to be at least two issues involved here. It's a pain to debug this large app with all its unmanaged and managed code so I sticked with investigating windbg behaviour in hope that's the same issue as VS.NET 2005

Basically the message sequence for the affected window goes like this (5 calls of that winproc):

(#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (#3) WM_NCPAINT (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT

After that sequence, the window refresh is finished.

The info for the affected window (opened via toolbar):

Parent (top level):

I made note of each user32 call within the app window proc to keep things simple.

After comparing both sequences, I noticed the following problem:

hRegionClip = NULL; Flags = DCX_WINDOW | DCX_INTERSECTRGN;

The call to user32.GetDCEx( hWndScratchWindow, hRegionClip, Flags) returned NULL on Windows XP while Wine returned a valid DC.

After further investigation with google it seems this is some sort of undocumented behaviour, see: http://www.virtualdub.org/blog/pivot/entry.php?id=37

--- quote --- As a side note, a poster on the forum recently helped me track down an irritating bug in VirtualDub's draggable video frames that was causing some instability on Win9x platforms. It happened because of a code fragment that I adapted from the MSDN Library documentation for WM_NCPAINT that supposedly helps you draw custom window frames. Well, the code fragment as given doesn't work, because it lacks an essential flag. GetDCEx() simply returns NULL and leaves the error code as NO_ERROR. You need to add 0x10000, called "an undocumented flag which can magically make GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the function to actually return a usable DC. It turns out that there is an even worse problem with the code as given because it causes window regions to be doubly freed! On Win9x, this results in an occasional crash in 16-bit GDI. (This particular problem with the WM_NCPAINT example is also colorfully documented in comments in the WINE source code.) After I fixed this issue, the poster's problem went away. So if you are using a Win9x platform, expect some stability improvements in edit mode in 1.6.4. --- quote ---

I patched dlls/user32/painting.c:GetDCEx for testing purposes but it didn't solve the endless looping problem.

The call sequences within that app window proc where GetDCEx was involved were more matching, showing slight improvement over previous situation. It seems the app directly checked for GetDCEx() returning NULL and took that into account (expecting such result). It remains mysterious why a Micro$oft app actually made this call with hard coded flags when it's expected to return NULL? Maybe the people there don't talk to each other/suffer from their own MSDN hell ;-) Maybe some Windows versions show different behaviour? This has to be added to conformance test ...

Regards

wine-bugs＠winehq.org

10:51 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #6 from Anastasius Focht focht@gmx.net 2008-07-22 17:51:56 --- Created an attachment (id=14992) --> (http://bugs.winehq.org/attachment.cgi?id=14992) Recorded call sequences from window proc (wine, endless paint looping)

Hello again,

attached is the call sequence in Wine for comparison. Note: I didn't use WINEDEBUG but my debugger+scratchpad to keep same style for better comparison (diffing) with previously posted attachment.

In short:

Wine:

(#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCACTIVATE (active = FALSE) (#4) WM_NCPAINT (Region = 00000001) .. <repeats forever (same as #4)> ..

This is different from previously posted behaviour of app in Windows:

(#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCPAINT (Region = 0004083B, valid region) (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT (Region = BB040864, valid region) <refresh finished, ends here>

Regards

wine-bugs＠winehq.org

11:19 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #7 from Anastasius Focht focht@gmx.net 2008-07-22 18:19:46 --- Created an attachment (id=14993) --> (http://bugs.winehq.org/attachment.cgi?id=14993) +tid,+seh,+msg,+win,+relay showing endless paint loop problem

Hello,

attached is full relay (cut to ~24000 lines) showing the problem.

Regards

wine-bugs＠winehq.org

23 Jul 23 Jul

6:33 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #8 from Anastasius Focht focht@gmx.net 2008-07-23 01:33:00 --- Created an attachment (id=14999) --> (http://bugs.winehq.org/attachment.cgi?id=14999) callstack each time frame wnd proc is entered

Hello,

I attached winedbg session of windbg, showing the callstack each time the frame window proc is entered. Sequence is same as described in previous posts.

Regards

wine-bugs＠winehq.org

17 Jan 17 Jan

12:13 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Anastasius Focht focht@gmx.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |0.9.49.

wine-bugs＠winehq.org

1 Jul 1 Jul

2:17 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #9 from Austin Lund austin.lund@gmail.com 2009-06-30 21:17:01 --- Created an attachment (id=22120) --> (http://bugs.winehq.org/attachment.cgi?id=22120) Crazy program to show the behaviour

Attached is a program which shows this. In windows it shows the hdc is zero. In wine it is 1e0 (for me).

wine-bugs＠winehq.org

6:18 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Austin Lund austin.lund@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |austin.lund@gmail.com

--- Comment #10 from Austin Lund austin.lund@gmail.com 2009-07-01 01:18:48 --- The WM_NCPAINT message for this window calls RedrawWindow(hWnd,NULL,NULL,0x441). Would this trigger repainting of everything and hence another WM_NCPAINT message?

wine-bugs＠winehq.org

7:16 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #11 from Austin Lund austin.lund@gmail.com 2009-07-01 02:16:14 --- Created an attachment (id=22121) --> (http://bugs.winehq.org/attachment.cgi?id=22121) Very simple program with identical painting behaviour

I've written a program which calls RedrawWindow in WM_NCPAINT in the same way as the windbg program does. It exhibits identical looping behaviour.

I haven't tested it on windows to see what it does.

wine-bugs＠winehq.org

2 Jul 2 Jul

12:52 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #12 from Austin Lund austin.lund@gmail.com 2009-07-01 19:52:37 --- I've tested my trial program on WinXPsp2 and the program doesn't do an infinite loop.

In wine my test program does:

WM_PAINT WM_NCPAINT WM_PAINT WM_NCPAINT WM_NCPAINT WM_PAINT WM_NCPAINT WM_NCPAINT (last 3 messages repeated forever)

In my version of XPsp2 it does:

WM_NCPAINT WM_NCPAINT WM_PAINT WM_NCPAINT (stops)

wine-bugs＠winehq.org

5:43 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #13 from Austin Lund austin.lund@gmail.com 2009-07-02 00:43:10 --- Created an attachment (id=22138) --> (http://bugs.winehq.org/attachment.cgi?id=22138) Test case

It seems that when there is this redraw in the WM_NCPAINT message handler and both the RDW_FRAME and RDW_INVALIDATE flags are set, then there is always an area (the non-client area) that is left flagged as needing to be updated.

This patch adds a test for this. On windows after an WM_PAINT message the area needing to be updated is NULL. On wine there is still a region needing to be updated.

wine-bugs＠winehq.org

3 Jul 3 Jul

4:42 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #14 from Austin Lund austin.lund@gmail.com 2009-07-02 23:42:24 --- I think I've found the reason for this. It seems that when wine does BeginPaint() it checks to see if the non-client area is within the update region. When doing this check, the region is validated in that step. If there is a region that needs updating a WM_NCPAINT message is sent. In this case the RedrawWindow() function will invalidate the whole thing. There is nowhere else that this can become valid. And hence at EndPaint() things are still marked as invalid. Then a WM_PAINT message is added and things go round again.

To explain this I've tried to do some psuedocode of what happens on wine and windows:

Wine:

WndProc WM_PAINT DefWndProc(WM_PAINT) BeginPaint() send_ncpaint() get_update_region() // Region Validated ... SendMessageW(WM_NCPAINT) WndProc WM_NCPAINT RedrawWindow() // Invalidates window DefWndProc(WM_NCPAINT) // Still invalid ... EndPaint() // Still Invaid As the window is marked invalid It calls WM_PAINT again.

Windows:

WndProc WM_PAINT DefWndProc(WM_PAINT) BeginPaint() FindUpdateRegion() // Does not validate region SendMessageW(WM_NCPAINT) // Still region invalid WndProc WM_NCPAINT RedrawWindow() // Region still invalid so does not matter DefWndProc(WM_NCPAINT) // Still Invalid ... // Painting instructions ValidateUpdateRegion() // Finally Validated Update Region ... EndPaint() // Region fully validated Nothing marked as invalid!

wine-bugs＠winehq.org

9 Jul 9 Jul

5:59 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #15 from Austin Lund austin.lund@gmail.com 2009-07-09 00:59:10 --- There seem to be two confounding effects here.

a) When DispatchMessage() is called on a WM_PAINT message in wine, the WNDPROC is called and then _after_ it has done what it does, if parts of the window are still marked as invalid they are updated using GetUpdateRgn(..,..,TRUE). This doesn't seem to happen in windows. The WM_NCPAINT and WM_ERASEBACKGROUND messages seem to be processed in a WM_PAINT message _before_ the WNDPROC is called.

b) When BeginPaint() is called and a WM_NCPAINT message is processed within it, the window is marked as invalid in wine when BeginPaint() returns. In windows a BeginPaint() seems to mark everything as clean even if WM_NCPAINT called RedrawWindow(..,..,..,0x401).

wine-bugs＠winehq.org

15 Jul 15 Jul

9:28 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Volodymyr Shcherbyna volodymyr@shcherbyna.com changed:

--- Comment #16 from Volodymyr Shcherbyna volodymyr@shcherbyna.com 2009-07-15 16:28:47 --- *** This bug has been confirmed by popular vote. ***

wine-bugs＠winehq.org

30 Apr 30 Apr

8:02 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Austin English austinenglish@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase

wine-bugs＠winehq.org

8:03 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Austin English austinenglish@gmail.com changed:

--- Comment #17 from Austin English austinenglish@gmail.com 2010-04-30 15:03:03 --- (From update of attachment 22138) Testcase is in wine: http://source.winehq.org/git/wine.git/?a=commitdiff;h=65758cde7f8a131f7bdc16...

and still a todo_wine, so not fixed.

wine-bugs＠winehq.org

15 Aug 15 Aug

6:47 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #18 from Austin Lund austin.lund@gmail.com 2010-08-15 01:47:12 --- (In reply to comment #15)

b) When BeginPaint() is called and a WM_NCPAINT message is processed within it, the window is marked as invalid in wine when BeginPaint() returns. In windows a BeginPaint() seems to mark everything as clean even if WM_NCPAINT called RedrawWindow(..,..,..,0x401).

On further investigation, this seems to be the more important part.

BeginPaint() should leave the whole thing validated even under the conditions for this bug. This means that the validation should occur AFTER all the other window messages are sent and processed (such as WM_NCPAINT in this case). Currently it happens with a call of get_update_region to the wineserver before any of the messages are sent. Reversing this is probably the key.

wine-bugs＠winehq.org

3 Sep 3 Sep

9:51 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Jerome Leclanche adys.wh@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com

--- Comment #19 from Jerome Leclanche adys.wh@gmail.com 2010-09-03 16:51:15 CDT --- Bug 17088 is likely a duplicate of this bug. Could someone check? The app is affected by the infinite loop, but I have no idea if it would cause the issues described there.

wine-bugs＠winehq.org

18 Sep 18 Sep

9:26 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #20 from Jerome Leclanche adys.wh@gmail.com 2010-09-18 16:26:01 CDT --- *** Bug 17088 has been marked as a duplicate of this bug. ***

wine-bugs＠winehq.org

9:35 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Thomas Spear Speeddymon@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |Speeddymon@gmail.com

--- Comment #21 from Thomas Spear Speeddymon@gmail.com 2010-09-18 16:35:16 CDT --- (In reply to comment #20)

*** Bug 17088 has been marked as a duplicate of this bug. ***

Bug 17088 does not result in 100% cpu (not even on 1 core), that I have ever noticed when I've encountered it personally.

wine-bugs＠winehq.org

9:35 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #22 from Jerome Leclanche adys.wh@gmail.com 2010-09-18 16:35:53 CDT --- (In reply to comment #21)

(In reply to comment #20)

...
*** Bug 17088 has been marked as a duplicate of this bug. ***

Bug 17088 does not result in 100% cpu (not even on 1 core), that I have ever noticed when I've encountered it personally.

Certainly does here.

wine-bugs＠winehq.org

9:39 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #23 from Thomas Spear Speeddymon@gmail.com 2010-09-18 16:39:37 CDT --- Strange indeed.

I don't have WoW installed at the moment, but I probably should for testing things like this.

wine-bugs＠winehq.org

10:50 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #24 from Jerome Leclanche adys.wh@gmail.com 2010-09-18 17:50:41 CDT --- (In reply to comment #23)

Strange indeed.

I don't have WoW installed at the moment, but I probably should for testing things like this.

The WoW trial client should suffice for testing this.

wine-bugs＠winehq.org

19 Sep 19 Sep

1:10 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Dan Kegel dank@kegel.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com

--- Comment #25 from Dan Kegel dank@kegel.com 2010-09-18 20:10:49 CDT --- Wait, how do you reproduce this with WoW?

wine-bugs＠winehq.org

1:12 a.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #26 from Dan Kegel dank@kegel.com 2010-09-18 20:12:32 CDT --- Oh, never mind, I read bug 17088 now.

wine-bugs＠winehq.org

23 Sep 23 Sep

8:10 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

Devin Cofer ranguvar@archlinux.us changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |ranguvar@archlinux.us

wine-bugs＠winehq.org

25 Oct 25 Oct

9:50 p.m.

New subject: [Bug 10522] endless WM_PAINT loop bug (update regions, queue paint count)

--- Comment #27 from Jerome Leclanche adys.wh@gmail.com 2011-10-25 16:50:50 CDT --- Still an issue in wine-1.3.31-58-g8994db9.

wine-bugs＠winehq.org

22 Jan 22 Jan

8:28 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools, World of Warcraft Launcher)

Anastasius Focht focht@gmx.net changed:

--- Comment #28 from Anastasius Focht focht@gmx.net 2012-01-22 14:28:08 CST --- Hello,

still present and found another app that suffers from this, constantly doing region (re)paint, eating one CPU. "FileTypeVerifier" from Windows Platform SDK 7.1.

--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Microsoft SDKs/Windows/v7.1/Bin ... $ wine ./FileTypeVerifier.exe --- snip ---

--- snip --- Wine-dbg>bt Backtrace: =>0 0x68001292 _dl_sysinfo_int80+0x2() in ld-linux.so.2 (0x0033f8b4) 1 0x6802e91e pthread_sigmask+0x4d() in libpthread.so.0 (0x0033f8b4) 2 0x7bc75131 wine_server_call+0x7a(req_ptr=0x33f8d0) [/home/focht/projects/wine/wine-git/dlls/ntdll/server.c:290] in ntdll (0x0033f8b4) 3 0x683d6f15 get_update_region+0x112(hwnd=0x10070, flags=0x33fa10, child=(nil)) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:547] in user32 (0x0033f984) 4 0x683d71b9 send_ncpaint+0x2a(hwnd=0x10070, child=(nil), flags=0x33fa10) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:626] in user32 (0x0033f9e4) 5 0x683d86e0 GetUpdateRgn+0x3c(hwnd=0x10070, hrgn=0xaa08, erase=0x1) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:1297] in user32 (0x0033fa24) 6 0x683cc987 DispatchMessageW+0x249(msg=0x33fbb8) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:3838] in user32 (0x0033fb34) 7 0x6838bc9b IsDialogMessageW+0x6d4(hwndDlg=0x2002a, msg=0x33fbb8) [/home/focht/projects/wine/wine-git/dlls/user32/dialog.c:1313] in user32 (0x0033fb94) 8 0x73c46e25 do_loop+0x32(psInfo=0x137ff0) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2732] in comctl32 (0x0033fbe4) 9 0x73c46fd6 PROPSHEET_PropertySheet+0xfb(psInfo=0x137ff0, unicode=0x1) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2775] in comctl32 (0x0033fc24) 10 0x73c473e1 PropertySheetW+0x1ec(lppsh=0x33fd04) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2868] in comctl32 (0x0033fc84) 11 0x01011463 in filetypeverifier (+0x11462) (0x0033fd80) 12 0x010114ca in filetypeverifier (+0x114c9) (0x0033fdac) 13 0x010121ba in filetypeverifier (+0x121b9) (0x0033fe40) --- snip ---

Download SDK: http://www.microsoft.com/download/en/details.aspx?id=8279

(SDK 7.1 installer needs .NET 4.0 Framework prerequisite installed)

$ sha1sum winsdk_web.exe a8717ebb20a69c7efa85232bcb9899b8b07f98cf winsdk_web.exe

$ wine --version wine-1.3.37-254-g14b790a

Regards

wine-bugs＠winehq.org

20 Apr 20 Apr

7:43 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools, World of Warcraft Launcher)

--- Comment #29 from Jerome Leclanche adys.wh@gmail.com 2013-04-20 14:43:42 CDT --- No longer reproducible using the wow launcher, as it's been rewritten.

wine-bugs＠winehq.org

21 Apr 21 Apr

7:09 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

Anastasius Focht focht@gmx.net changed:

--- Comment #30 from Anastasius Focht focht@gmx.net 2013-04-21 14:09:39 CDT --- Hello Jerome,

--- quote --- No longer reproducible using the wow launcher, as it's been rewritten. --- quote ---

Ok, removing the game from summary then. The bug is obviously still present with other apps (Windows SDK).

$ wine --version wine-1.5.28-133-g7d8f3a1

Regards

wine-bugs＠winehq.org

6 Apr 6 Apr

6:12 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

--- Comment #31 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, still present.

$ wine --version wine-1.7.40-29-gc1c108f

Regards

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

wine-bugs＠winehq.org

25 Oct 25 Oct

11:40 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

Sylvain Petreolle spetreolle@yahoo.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle@yahoo.fr

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

wine-bugs＠winehq.org

20 Jan 20 Jan

11:17 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop ( Platform SDK tools)

joaopa jeremielapuree@yahoo.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr

--- Comment #32 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.0-rc7?

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

wine-bugs＠winehq.org

3 Feb 3 Feb

10:22 a.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop ( Platform SDK tools)

--- Comment #33 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, still present.

--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/Debugging Tools for Windows (x86)

$ WINEDLLOVERRIDES=dbgeng=n wine ./windbg.exe ... --- snip ---

$ wine --version wine-4.0-276-g84459ba94b

Regards

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

10 Aug 10 Aug

4:31 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

https://web.archive.org/web/20190317014512/http://download.microsoft.com/dow...

--- Comment #34 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, still present.

Adding stable download links to 'Debugging Tools for Windows 6.12.x' via Internet Archive. They don't require Windows SDK installation (https://web.archive.org/web/20130131051038/http://www.microsoft.com/en-us/do...)

32-bit:

$ sha1sum dbg_x86.msi 117814c255f19dc67e769c668bc97e547c05a55b dbg_x86.msi

$ du -sh dbg_x86.msi 19M dbg_x86.msi

64-bit:

https://web.archive.org/web/20190317014905/http://download.microsoft.com/dow...

$ sha1sum dbg_amd64.msi 257978e5dc64ae8f8e2b591bd9c147178117d235 dbg_amd64.msi

$ du -sh dbg_amd64.msi 17M dbg_amd64.msi

$ wine --version wine-6.14-250-gcaf5ab5d65e

Regards

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

14 Nov 14 Nov

8:13 a.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

Anastasius Focht focht@gmx.net changed:

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

16 Feb 16 Feb

9:43 p.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)

--- Comment #35 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-20.1?

I could test by myself (there is a download) but I do not understand what the bug is about.

-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

WineHQ Bugzilla

17 Feb 17 Feb

10:44 a.m.

New subject: [Bug 10522] Multiple applications encounter infinite WM_PAINT loop (Platform SDK tools)