Code Quality: Sync the jump list with Explorer

[0x5bfa]

Resolved / Related Issues

• Related: Code Quality: Replace references to Vanara and WinForms with CsWin32 #15000
• Closes Code Quality: Copy jump list of Explorer to Files via IAutomaticDestinationList #17488
• Fixes Bug: JumpList Not Populating #14526
• Fixes Feature: Show actual folder icon in jump list #17659
• Fixes Feature: Files is pinned to my taskbar. When I right click on it, I'd like to see my quick access pins and pins I make #17631

TODOs

• Completely deletes the binaries for the Files' jump list on startup and on every update
• Watches the changes to the Explorer's jump list
• Watches the changes to the Files' jump list
• Replicates the Explorer's jump list to the Files' jump list
• Replicates the Files' jump list to the Explorer's jump list

Steps used to test these changes

• Build the app
• Cold-launch the app
• See its jump list being the same as the Explorer's jump list
• Pin/unpin an item from the Explorer's jump list
• See that of Files also gets updated
• Do the way around of above

[yaira2]

This might help with #14526

[Josh65-2201]

Would this fix #17659

[yaira2]

Would this fix #17659

I think so. @0x5bfa can you confirm?

[0x5bfa]

Yes. This is one of the motivation. (I updated the PR to include this)

[sentry]

Bug: A buffer overflow occurs because memory for a character buffer is allocated in bytes (MAX_PATH), but the size is passed to a WinAPI function as a character count, effectively halving the buffer's safe capacity.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

The code allocates memory for string buffers using ComHeapPtr<char>.Allocate(PInvoke.MAX_PATH), which allocates 260 bytes. Since a C# char is a 2-byte wide character, this buffer can only hold 130 characters. However, subsequent calls to Windows APIs like GetArguments and GetFolderIconLocation are told the buffer can hold MAX_PATH (260) characters. If the path or argument string returned by the API is longer than 130 characters, a buffer overflow will occur, writing past the allocated memory and likely causing a crash. This issue is present in multiple locations within JumpListManager.cs.

💡 Suggested Fix

When allocating memory for wide character strings, ensure the byte count is correctly calculated. Modify the allocation call to pszParseablePath.Allocate(PInvoke.MAX_PATH * sizeof(char)) to allocate enough space for 260 characters, not 260 bytes. Apply this fix to all similar API calls in the file.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/Files.App.Storage/Windows/Managers/JumpListManager.cs#L274-L276

Potential issue: The code allocates memory for string buffers using
`ComHeapPtr<char>.Allocate(PInvoke.MAX_PATH)`, which allocates 260 bytes. Since a C#
`char` is a 2-byte wide character, this buffer can only hold 130 characters. However,
subsequent calls to Windows APIs like `GetArguments` and `GetFolderIconLocation` are
told the buffer can hold `MAX_PATH` (260) characters. If the path or argument string
returned by the API is longer than 130 characters, a buffer overflow will occur, writing
past the allocated memory and likely causing a crash. This issue is present in multiple
locations within `JumpListManager.cs`.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 7681507}

[sentry]

Bug: The return value of EnumerateCategoryDestinations is not checked. If the call fails, a subsequent method call on the uninitialized poc pointer will cause a null pointer dereference.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

The HRESULT returned from the COM call pFilesICDL.Get()->EnumerateCategoryDestinations(...) is not checked for failure. If this call fails, the poc ComPtr will remain uninitialized (null). The subsequent line immediately attempts to dereference this pointer by calling poc.Get()->GetCount(...), which will result in a null pointer dereference and cause an access violation crash. This type of failure can occur under various system conditions, such as resource pressure or corrupted file stores.

💡 Suggested Fix

Add an error check immediately after the call to EnumerateCategoryDestinations. If the returned HRESULT indicates a failure, the function should return the error code to prevent the application from attempting to use the uninitialized poc pointer. For example: if (FAILED(hr)) return hr;.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/Files.App.Storage/Windows/Managers/JumpListManager.cs#L256-L260

Potential issue: The `HRESULT` returned from the COM call
`pFilesICDL.Get()->EnumerateCategoryDestinations(...)` is not checked for failure. If
this call fails, the `poc` `ComPtr` will remain uninitialized (null). The subsequent
line immediately attempts to dereference this pointer by calling
`poc.Get()->GetCount(...)`, which will result in a null pointer dereference and cause an
access violation crash. This type of failure can occur under various system conditions,
such as resource pressure or corrupted file stores.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 7681507}