locked
Property Sheet Extension tabs vanishes/destroys Under x64 Windows 10 RRS feed

  • Question

  • I have a property sheet shell extension that has 4 tabs. The extension functions correctly on Windows 7, Windows 8. I've attached a debugger to DllHost.exe which shows the IShellExtInit::Initialize() and IShellPropSheetExt::AddPages() functions run successfully. The file properties dialog is displayed including the additional tabs for my extension but when I select  any of them, tab disappears/destroys when used on a 64bit version of Windows 10.

    On debugging found that DlgProc call back is receiving message 144 after message 297, while on win 7(where working fine) it is receiving 295 after 297. This messages are defined in winUser.h , but message 144 is not present there also after getting message 144 , message 2 is received which is WM_DESTROY and hence causing the tab to destroy.But no idea from where 144 is coming.


    • Moved by Shu 2017 Friday, August 28, 2015 4:42 AM from VC++ forum
    Thursday, August 27, 2015 5:59 AM

All replies

  • Hi sshivani,

    I will move this to User Interface development for Windows Desktop forum since you are working with Shell APIs. Thanks for your understanding.

    I find something on the web, It seems that there are some messages are undocumented. WM_UAHDESTROYWINDOW 0x0090

    Best regards,

    Shu


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, August 28, 2015 4:42 AM
  • This message only gets sent from the kernel mode function which destroys windows (assuming the system is what sent it).  You'll have to look elsewhere to find why the window is being destroyed.  Is the first message you receive when you click on the tab one of the destroy messages?  If so, it could be that the system thinks that you've clicked outside of the dialog and it should be closed.

    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Friday, August 28, 2015 9:04 PM
  • Hi Chris,

    For same code getting executed, the sequence of messages are 48->85->297->144 on windows 10.

    While for windows 7, sequence of messages are -> 48->85->297 ->295- >296 and so on...

    can anything be derived out of this.

    Monday, August 31, 2015 12:43 PM
  • In the scenario on Windows 7, you're getting the following messages:

    WM_SETFONT

    WM_NOTIFYFORMAT

    WM_QUERYUISTATE

    WM_CHANGEUISTATE

    WM_UPDATEUISTATE

    In the scenario on Windows 10, you're getting the following messages:

    WM_SETFONT

    WM_NOTIFYFORMAT

    WM_QUERYUISTATE

    WM_UAHDESTROYWINDOW

    So it looks like things are changing based on WM_QUERYUISTATE.  What are you returning from your windowproc to WM_QUERYUISTATE?  You may also want to call DebugBreak when you get that message and step through the code from there.


    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Monday, August 31, 2015 7:10 PM
  • Hi Chris,

    Below is the call stack between signal WM_QUERYUISTATE and WM_UAHDESTROYWINDOW.

    ===============================================================

    NssShellExtPropSheetHandler.dll!CNSSRightsDialog::NSSRightsPageDlgProc(HWND__ * hWnd=0x00000000002c0532, unsigned int uMsg=0x00000090, unsigned __int64 wParam=0x0000000000000000, __int64 lParam=0x0000000000000000) Line 939 C++
    user32.dll!UserCallDlgProcCheckWow() Unknown
    user32.dll!DefDlgProcWorker() Unknown
    user32.dll!DefDlgProcW() Unknown
    user32.dll!UserCallWinProcCheckWow() Unknown
    user32.dll!DispatchClientMessage() Unknown
    user32.dll!__fnDWORD() Unknown
    ntdll.dll!KiUserCallbackDispatcherContinue() Unknown
    user32.dll!NtUserDestroyWindow() Unknown
    user32.dll!dummyImmGetCompositionWindow() Unknown
    user32.dll!CreateDialogIndirectParamAorW() Unknown
    user32.dll!CreateDialogIndirectParamW() Unknown
    comctl32.dll!_CreatePageDialog(struct PROPDATA const *,struct ISP *,struct HWND__ *,struct DLGTEMPLATE * const) Unknown
    comctl32.dll!_CreatePage(struct PROPDATA *,struct ISP *,struct HWND__ *,unsigned short) Unknown
    comctl32.dll!PageChange(struct PROPDATA *,int) Unknown
    comctl32.dll!`DuiTelemetry::Instance(void)'::`2'::`dynamic atexit destructor for 'wrapper''(void) Unknown
    user32.dll!UserCallDlgProcCheckWow() Unknown
    user32.dll!DefDlgProcWorker() Unknown
    user32.dll!DefDlgProcW() Unknown
    user32.dll!UserCallWinProcCheckWow() Unknown
    user32.dll!SendMessageWorker() Unknown
    user32.dll!SendMessageW() Unknown
    comctl32.dll!CCSendNotify() Unknown
    comctl32.dll!SendNotifyEx() Unknown
    comctl32.dll!ChangeSel() Unknown
    comctl32.dll!Tab_OnLButtonDown(struct TC *,int,int,unsigned __int64) Unknown
    comctl32.dll!Tab_WndProc() Unknown
    user32.dll!UserCallWinProcCheckWow() Unknown
    user32.dll!DispatchMessageWorker() Unknown
    user32.dll!IsDialogMessageW() Unknown
    comctl32.dll!Prop_IsDialogMessage(struct PROPDATA *,struct tagMSG *) Unknown
    comctl32.dll!_RealPropertySheet(struct PROPDATA *) Unknown
    comctl32.dll!_PropertySheet(struct _PROPSHEETHEADERW_V2 const *,int) Unknown
    shell32.dll!PropertySheetW() Unknown
    shell32.dll!SHOpenPropSheetW() Unknown
    shell32.dll!ExecutePropSheet(struct IDataObject *,unsigned short const *,struct _GUID const &) Unknown
    shell32.dll!Microsoft::WRL::Details::ComPtrRef<class Microsoft::WRL::AgileRef>::operator class Microsoft::WRL::AgileRef *(void) Unknown
    shell32.dll!Windows::Internal::ComTaskPool::CThread::_ThreadProc(void) Unknown
    shell32.dll!Windows::Internal::ComTaskPool::CThread::s_ExecuteThreadProc(void *) Unknown
    shell32.dll!Windows::Internal::ComTaskPool::CThread::s_ThreadProc(void *) Unknown
    kernel32.dll!BaseThreadInitThunk() Unknown
    ntdll.dll!RtlUserThreadStart() Unknown

    ======================================================================

    These signals are not getting handled in DlgProc specifically.Just returning "False" for windows to handle them.

                                            
    Tuesday, September 1, 2015 5:57 AM
  • I don't see anything that tells us more than we knew before from that stack.  It seems like the most likely cause would be that focus has been lost.

    WinSDK Support Team Blog: http://blogs.msdn.com/b/winsdk/

    Wednesday, September 9, 2015 7:39 PM