Hello,
We have a serious issue within Windows XP release (Beta 2, RC1 and RC2 tested also, no difference). When using the Fast User Switching of windows XP at a particular moment of our application, the application memory is corrupted and it crashs.
The problem happens when switching back from another user to the user running the application. The memory corruption occurs either within an MFC class (a MFC internal handler have been incorrectly set to "15", which is in fact the value of the WM_PAINT message) or within an application own DLL class destruction (also there, some handle becomes incorrect).
This happens when the application is computing, displaying a modal progress dialog with several threads running on the back ground. On other places, the application is mono-threaded and runs fine during the F.U.S. even if it is busy or access hardware and DLL.
The application allready uses a global mutex to avoid several runs of itself. This have been tested and the application detects itself very well.
The problematic modal dialog register for F.U.S. notification and this 'works' well also (eg. we get the notification).
If we disable refreshing of the dialog by setting the window to hidden, the computing process continue till the end (it can take several minute) until it finish and try to free object within a DLL and crashs.
If we do not disable the refresh, on first redraw of the dialog the crash within MFC occurs.
Of course the application is well tested under Windows 9x, Me, NT and 2k and we never get such troubles there. Some other minor troubles have been found also under windows XP, most of them cosmetic troubles, but have been all fixed allready.
We will be very interested if someone got a similar trouble with F.U.S. or if someone got additionnal information about what XP do with memory when switching.
All documentation from Microsoft (MSDN and other) I can find in application compatibility, or about F.U.S. of XP, is limited to implemented true user separation, register for session change, or limiting the running instance to 1. Nothing about handle that may be closed, Ole component we shouldn't use and something like that.
We also try to set hardware breakpoints on handles that are modified, but we only lands into MFC code about message handling. Could it be that it is required to update MFC for XP ? I seek myself for updated MFC but didn't found one.
Any help welcome,
David Burg.
We have a serious issue within Windows XP release (Beta 2, RC1 and RC2 tested also, no difference). When using the Fast User Switching of windows XP at a particular moment of our application, the application memory is corrupted and it crashs.
The problem happens when switching back from another user to the user running the application. The memory corruption occurs either within an MFC class (a MFC internal handler have been incorrectly set to "15", which is in fact the value of the WM_PAINT message) or within an application own DLL class destruction (also there, some handle becomes incorrect).
This happens when the application is computing, displaying a modal progress dialog with several threads running on the back ground. On other places, the application is mono-threaded and runs fine during the F.U.S. even if it is busy or access hardware and DLL.
The application allready uses a global mutex to avoid several runs of itself. This have been tested and the application detects itself very well.
The problematic modal dialog register for F.U.S. notification and this 'works' well also (eg. we get the notification).
If we disable refreshing of the dialog by setting the window to hidden, the computing process continue till the end (it can take several minute) until it finish and try to free object within a DLL and crashs.
If we do not disable the refresh, on first redraw of the dialog the crash within MFC occurs.
Of course the application is well tested under Windows 9x, Me, NT and 2k and we never get such troubles there. Some other minor troubles have been found also under windows XP, most of them cosmetic troubles, but have been all fixed allready.
We will be very interested if someone got a similar trouble with F.U.S. or if someone got additionnal information about what XP do with memory when switching.
All documentation from Microsoft (MSDN and other) I can find in application compatibility, or about F.U.S. of XP, is limited to implemented true user separation, register for session change, or limiting the running instance to 1. Nothing about handle that may be closed, Ole component we shouldn't use and something like that.
We also try to set hardware breakpoints on handles that are modified, but we only lands into MFC code about message handling. Could it be that it is required to update MFC for XP ? I seek myself for updated MFC but didn't found one.
Any help welcome,
David Burg.
