Windows 11 shell extension on MTP

[JeromeMartinez]

From email.

"The shell extension worked before with MTP devices like my camera and I also could open those media files from MediaInfo. Those features are no longer possible"

Confirmed that it does not work now, not tested with an older version.

[JeromeMartinez]

@cjee21 it may comme from the migration from old system to the "modern" Win11 style, could you check what you can do?

[cjee21]

Only some Microsoft and Google shell extensions work for MTP. Others all missing.

I ask Google Gemini 3.5 and it says MTP are special. Need to make quite some changes and even then, you will get \\?\usb#vid_04e8&pid_6860&ms_comp_mtp&samsung_android#6&1a2b3c4d&0&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}\SID-{10001,0000000000000012,98765432} path (can MediaInfo handle this?) or if Windows knows (how?) app cannot support this then Windows will copy the entire file to %TEMP% first before opening in app.

PS I do not like opening files directly from MTP, Windows always copy to %TEMP% before opening so takes time to open and there will be writes to %TEMP% which I hope will be deleted automatically.

[JeromeMartinez]

Only some Microsoft and Google shell extensions work for MTP. Others all missing.

Not sure to understand, anyway it works on Win10 and MTP (copying the file in a temp dir, and sending the temp name to MediaInfo).

\?\usb#vid_04e8&pid_6860&ms_comp_mtp&samsung_android#6&1a2b3c4d&0&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}\SID-{10001,0000000000000012,98765432} path (can MediaInfo handle this?)

Never tried, but we send the path directly to the OS, should be OK, we can check.

PS I do not like opening files directly from MTP, Windows always copy to %TEMP% before opening so takes time to open and there will be writes to %TEMP% which I hope will be deleted automatically.

But some users like it, I prefer to let the user choose.
If we can avoid the copy, it would be even better, but if not, still better to use the old Win10 method (copy then temp name) than nothing.

Would you mind to check what could be done there?

[cjee21]

Okay I see what is going on now. It does load MediaInfo shell extension when right-click MTP. So issue must be our filtering of supported filetypes.

[cjee21]

It's late now so I will be checking tomorrow onwards if I am free. Meanwhile, here is what Gemini suggests. I'll just leave it here, you can try if you want.

Gemini 3.5 Flash output

If your DLL is actively loading when you right-click an item inside an MTP device, it means your MSIX manifest registration is actually working perfectly! The Windows Shell is reading the manifest, matching the file type context, locating your class ID, and successfully spinning up your DLL.

The reason your menu item isn't appearing comes down to a classic mismatch between what your C++ code is returning and what the virtual MTP environment expects.

When your DLL loads, the Shell immediately calls your implementation of IExplorerCommand::GetState to decide whether it should display, hide, or disable your menu item. This is where the break happens.

---

The Culprit: Strict GetState Checks

Most sample implementations of IExplorerCommand::GetState look something like this:

IFACEMETHODIMP CMyCommand::GetState(IShellItemArray *psiItemArray, BOOL fOkToBeSlow, EXPCMDSTATE *pCmdState)
{
    *pCmdState = ECS_HIDDEN; // Default to hidden

    // Typcial verification code...
    DWORD count = 0;
    psiItemArray->GetCount(&count);
    
    for (DWORD i = 0; i < count; i++)
    {
        PIDLIST_ABSOLUTE pidl;
        // ❌ TRAP 1: Trying to get a PIDL or path
        HRESULT hr = SHGetIDListFromObject(psiItemArray, &pidl); 
        
        // ❌ TRAP 2: Checking standard Win32 attributes
        SFGAOF attributes;
        hr = psiItemArray->GetAttributes(IAG_ALL, SFGAO_FILESYSTEM, &attributes);
        if (!(attributes & SFGAO_FILESYSTEM)) {
            return S_OK; // Silently hides the menu because MTP items are NOT SFGAO_FILESYSTEM!
        }
    }

    *pCmdState = ECS_ENABLED; // Show the menu item
    return S_OK;
}

Because MTP items reside in a virtual Shell namespace, they fail standard file-system validations. If your code does any of the following inside GetState, your menu item will instantly vanish:

• Checking if the items have the SFGAO_FILESYSTEM attribute.
• Attempting to call IShellItem::GetDisplayName with SIGDN_FILESYSPATH (which fails on MTP) and checking the string extension yourself.
• Failing the entire loop if any single HRESULT returns an error code when querying standard physical file traits.

How to Fix Your Code

You need to loosen up your GetState function so it can gracefully handle virtual shell objects.

1. Quick Verification Hack

To prove beyond a shadow of a doubt that your code is hiding the menu, temporarily hardcode your GetState function to unconditionally show the item:

IFACEMETHODIMP CMyCommand::GetState(IShellItemArray *psiItemArray, BOOL fOkToBeSlow, EXPCMDSTATE *pCmdState)
{
    // Hardcode to visible to bypass your internal checks
    *pCmdState = ECS_ENABLED; 
    return S_OK;
}

Compile, deploy, and right-click an MTP file. Your menu item should pop right up in the context menu.

2. The Robust MTP-Aware Implementation

Once you confirm that it's your code hiding it, replace your validation loop with one that accepts virtual items. Instead of forcing a physical path check, use SIGDN_NORMALDISPLAY or verify against SFGAO_STREAM (since MTP files can be streamed):

IFACEMETHODIMP CMyCommand::GetState(IShellItemArray *psiItemArray, BOOL fOkToBeSlow, EXPCMDSTATE *pCmdState)
{
    *pCmdState = ECS_HIDDEN;

    if (!psiItemArray) return S_OK;

    DWORD count = 0;
    if (FAILED(psiItemArray->GetCount(&count)) || count == 0) return S_OK;

    for (DWORD i = 0; i < count; i++)
    {
        ComPtr<IShellItem> item;
        if (SUCCEEDED(psiItemArray->GetItemAt(i, &item)))
        {
            // Instead of checking for a physical path, check if it has a display name.
            // Virtual MTP files will successfully return their plain filename here.
            LPWSTR pszName = nullptr;
            if (SUCCEEDED(item->GetDisplayName(SIGDN_NORMALDISPLAY, &pszName)))
            {
                CoTaskMemFree(pszName);
            }
            else
            {
                // If it can't even get a display name, hide it.
                return S_OK; 
            }
        }
    }

    // If we passed the basic checks, show the item!
    *pCmdState = ECS_ENABLED; 
    return S_OK;
}

Double-Check IExplorerCommand::Invoke

Keep in mind that once you fix GetState, your Invoke method will run into the exact same issue if it tries to fetch SIGDN_FILESYSPATH. Be sure to update your execution logic to pull the stream or parsing path instead of a standard C:\ string, as we touched on earlier!

[cjee21]

By the way, Windows SmartScreen is still blocking MediaInfo installer until now even after few months with the new cert. Wonder why.

[cjee21]

update: returning ECS_ENABLED for everything in GetState makes MediaInfo appear in context menu for MTP but clicking it results in blank MediaInfo.

[JeromeMartinez]

but clicking it results in blank MediaInfo.

Idea about the file name provided to MediaInfo?
anyway, it is better and then issue only in MediaInfo, another step.

By the way, Windows SmartScreen is still blocking MediaInfo installer until now even after few months with the new cert. Wonder why.

For me it is fine, and no idea about what to change there is there is something doable.

[cjee21]

Idea about the file name provided to MediaInfo?

Looks like no command line arguments passed when launching according to Process Explorer. So we need to figure out how to get the path of an MTP file.

[cjee21]

Okay. This patch will make MediaInfo appear for every type of MTP item (did not manage to retrieve the filename to check extension). Then, it will pass the path of that item as command line argument to launch MediaInfo (but MediaInfo cannot handle).

MediaInfoShellMTP.patch

[cjee21]

Path/string passed to MediaInfo will look like (this example is AI generated but looks similar to actual that I checked):

"::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\\\?\usb#vid_04e8&pid_6860&ms_comp_mtp&sany_inst#7&30be908f&0&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}\SID-{20002,O102A,15053422592}\o105A"

[JeromeMartinez]

@cjee21 coud you try something like below for getting the real file extension? So you could filter as usual.

#include <shobjidl.h>
#include <shlwapi.h>

IShellItem* item = nullptr;

HRESULT hr = SHCreateItemFromParsingName(
    parsingPath,
    nullptr,
    IID_PPV_ARGS(&item));

if (SUCCEEDED(hr))
{
    PWSTR name = nullptr;

    hr = item->GetDisplayName(SIGDN_NORMALDISPLAY, &name);

    if (SUCCEEDED(hr))
    {
        wprintf(L"Filename: %s\n", name);

        CoTaskMemFree(name);
    }

    item->Release();
}

On MediaInfoLib side, looks like that I could parse the file without temporary copy, but I should expect that I can not always seek.

[cjee21]

I tried many things already. Just get either a large number or a GUID string.

[cjee21]

SIGDN_NORMALDISPLAY gives filename without extension (because I do not show extensions in File Explorer?).
SIGDN_PARENTRELATIVEPARSING gives GUID that is the last segment of path below.
SIGDN_DESKTOPABSOLUTEPARSING gives long virtual path with no filename or extension.

But there is a way... need query from COM.