Addin: QueryStatus and Exec Methods (C++/ATL)


  • Hi All,

    For completeness and the benefit of others who stumble across this thread, here is what I found for QueryStatus Other results are similar. I imagine most on this social do not care about HRESULTs and such, but again, it is for the benefit of others who wander onto the thread. Results were obtained by running Visual Studio under WinDbg.

    Visual Studio (msenv.exe) calls AddinPerformQueryStatus to query an add-in status. This was obtained by BP'ing the Add-in's QueryStatus, and then examining the stack:

    0:000> k  
    ChildEBP RetAddr    
    0012f190 5034e125 CryptoPPAddIn!CConnect::QueryStatus  
    0012f204 500780f8 msenv!AddinPerformQueryStatus+0x144  
    0012f25c 5007874e msenv!CVSCommandTarget::QueryStatusCmd+0x1c8  
    0012f294 50078bbf msenv!CVSShellMenu::IsCommandVisible+0x70  
    0012f2fc 50078be4 msenv!CVSShellMenu::IsCommandVisible+0x156  

    Next, a BP on the return address (780F8). At the BP, an unassemble:

    0:000> u 500780f8 500780f8+100  
    500780f8 8bf8            mov     edi,eax  
    500780fa 85ff            test    edi,edi  
    500780fc 7c53            jl      msenv!CVSCommandTarget::QueryStatusCmd+0x245 (50078151) 

    EAX is the add-in's return value. TEST is an AND that does not store results. JL is jump if less than (signed comparison).  TEST EDI, EDI ic checking the return value to see if it is negative. This would translate to 'if( SUCCEEDED(hr) )'. This tells me that S_OK and S_FALSE are not discriminated.

    If an error code is returned, a jump is made to 78151:

    0:000> u 50078151 50078151+50  
    50078151 c644244000      mov     byte ptr [esp+40h],0  
    50078156 8b442428        mov     eax,dword ptr [esp+28h]  
    5007815a 85c0            test    eax,eax  
    5007815c 7408            je      msenv!CVSCommandTarget::QueryStatusCmd+0x25a (50078166)  
    5007815e 8b10            mov     edx,dword ptr [eax]  
    50078160 50              push    eax  
    50078161 8b4208          mov     eax,dword ptr [edx+8]  
    50078164 ffd0            call    eax  
    50078166 c7442440ffffffff mov     dword ptr [esp+40h],0FFFFFFFFh  
    5007816e 56              push    esi  
    5007816f ff15f81a0050    call    dword ptr [msenv!_imp__SysFreeString (50001af8)]  
    50078175 e9acfbffff      jmp     msenv!CVSCommandTarget::QueryStatusCmd+0x269 (50077d26)  
    5007817a 81ff04010480    cmp     edi,80040104h  
    50078180 0f84a1010000    je      msenv!CVSCommandTarget::QueryStatusCmd+0x372 (50078327)  
    50078186 85ff            test    edi,edi  
    50078188 0f8599010000    jne     msenv!CVSCommandTarget::QueryStatusCmd+0x372 (50078327)  
    5007818e f6460401        test    byte ptr [esi+4],1  
    50078192 0f848f010000    je      msenv!CVSCommandTarget::QueryStatusCmd+0x372 (50078327)  

    Above, Visual Studio is trying to find a handler for the command since our add-in did not take responsibility. If a command handler is found, all apears OK. Otherwise, jump to 50078327 and remove the command.

    Most interesting from above is 80040104. It is not listed in winerror.h. Searching the web does not get back the phone book as expected. So it appears it may be an undocumented code similar to 'handler not found'. I suspect it is returned from QueryService [1] or similar API call. What this most likely means is that there is a problem in registration database - that is, the Registry entry for the handler is hosed up.

    ** Conclusions **
     * Ok
    * OK (handled as S_OK)
    * fail and remove the command handler from the chain
    * attempt to find another handler


    • Marked as answer by Wesley Yao Tuesday, March 24, 2009 2:23 AM
    Friday, March 20, 2009 6:28 AM