#17 Crash on fast switch

closed-fixed
nobody
None
5
2007-06-21
2006-11-17
Conrado PLG
No

Apps with WidgetMenuExtended crash when fast switching (Win+L).

Open the WidgetMenu test and fast switch: the app will crash.

An exception "Couldn't bit blast in blast()" is thrown in WidgetMenuExtended::drawItem > canvas.blast.

GetLastError returns ERROR_INVALID_HANDLE.

Discussion

  • Conrado PLG

    Conrado PLG - 2006-12-07

    Logged In: YES
    user_id=1103883
    Originator: YES

    It works if we stop the library from throwing an exception if the BitBlt call fails, inside BufferedCanvas::blast. I don't think it's a good solution, but I don't think making the app crash is good either... so what do you think we should do?

    I have no idea why the BitBlt call fails.

     
  • Sergey Hakobyan

    Sergey Hakobyan - 2007-02-08

    Logged In: YES
    user_id=753908
    Originator: NO

    It seems DC handle becomes invalid for a moment while using FUS.
    I'll check this up and let you know if solution other then commenting the throwing exception can be found.

     
  • Sergey Hakobyan

    Sergey Hakobyan - 2007-02-09

    Logged In: YES
    user_id=753908
    Originator: NO

    Hi developers!

    I've analyzed the issue and found out that the problem occurs because WM_DRAWITEM message is sent to the application before the session is actually unlocked (session gets locked during Fast User Switching or explicitly locking it (Win+L combination)).
    There is a way to receive the messages about session locking. As the Fast User Switching is based on Terminal Services, we can register to receive "WM_WTSSESSION_CHANGE" message using WTSRegisterSessionNotification/WTSUnRegisterSessionNotification functions. Later we could check if message.wParam == WTS_SESSION_LOCK.
    The problem in applying the bugfix is that WM_WTSSESSION_CHANGE is sent LATER then WM_DRAWITEM, but its existance should be checked BEFORE is it processed. Thus in WM_DRAWITEM handler it should be checked if WM_WTSSESSION_CHANGE is somewhere in the message queue or not (waiting still to be processed). I've tried to use PeekMessage with PM_NOREMOVE parameter, but it fails sometimes to find the WM_WTSSESSION_CHANGE.
    So the possible solutions are
    1. either check the WM_WTSSESION_CHANGE before it is actually processed (is it possible?) or
    2. prevent throwing exceptions in case "blasting" fails with error code 5/6 (access denied/invalid handle).

    Please advice :)
    Thanks!

     
  • Sergey Hakobyan

    Sergey Hakobyan - 2007-02-23

    Logged In: YES
    user_id=753908
    Originator: NO

    Solved using the trick of GetForegroundWindow(), which returns NULL in case of fast user switching (when the session is being locked/unlocked).

     
  • andrew7

    andrew7 - 2007-06-21
    • status: open --> closed-fixed
     
  • andrew7

    andrew7 - 2007-06-21

    Logged In: YES
    user_id=1157678
    Originator: NO

    Tried Win-L on Widget Menu in Vista, problem did not occur.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks