A
asfarley
Guest
I'm working on an MFC application under VS2019 targeting Windows 10.
We have an issue where some interaction with the scroll-bars is causing the application to hang. It's tough to reproduce every time, but I find that moving one scroll-bar (i.e. the horizontal bar) and then clicking on the vertical scroll-bar tends to trigger the issue. When this happens, our application (as well as the entire Windows desktop!) hangs for about 30 seconds, before recovering and going back to normal.
We don't have any CPU-intensive tasks in the scroll handlers (as far as I know) and Task Manager/Performance Monitor also confirm that CPU usage is very low when this issue occurs (1-3%).
Our application uses a relatively low count of GDI and User objects (under 200) so I don't think this is related to the GDI/User Object limit.
I've posted this issue on StackOverflow here:
Why is my MFC application hanging after interacting with both scroll-bars?
I'm hoping for some support from Microsoft staff, because this seems to be related to the OS and it's a fairly unique issue which StackOverflow doesn't really like.
To debug, I tried watching the messages in our application via Spy++. However, I discovered that Spy++ prevents the issue from happening. Can someone familiar with Spy++ give some suggestions about how this might happen?
My guesses are that a) Spy++ causes a delay, which may resolve a hidden race condition or b) Spy++ 'unsticks' whatever is going wrong with the message pump.
Continue reading...
We have an issue where some interaction with the scroll-bars is causing the application to hang. It's tough to reproduce every time, but I find that moving one scroll-bar (i.e. the horizontal bar) and then clicking on the vertical scroll-bar tends to trigger the issue. When this happens, our application (as well as the entire Windows desktop!) hangs for about 30 seconds, before recovering and going back to normal.
We don't have any CPU-intensive tasks in the scroll handlers (as far as I know) and Task Manager/Performance Monitor also confirm that CPU usage is very low when this issue occurs (1-3%).
Our application uses a relatively low count of GDI and User objects (under 200) so I don't think this is related to the GDI/User Object limit.
I've posted this issue on StackOverflow here:
Why is my MFC application hanging after interacting with both scroll-bars?
I'm hoping for some support from Microsoft staff, because this seems to be related to the OS and it's a fairly unique issue which StackOverflow doesn't really like.
To debug, I tried watching the messages in our application via Spy++. However, I discovered that Spy++ prevents the issue from happening. Can someone familiar with Spy++ give some suggestions about how this might happen?
My guesses are that a) Spy++ causes a delay, which may resolve a hidden race condition or b) Spy++ 'unsticks' whatever is going wrong with the message pump.
Continue reading...