explorer.exe crashes (c0000005) parsing XYplorer's "Shell IDList Array" clipboard data after Ctrl+C

[marksooxx]

1) XYplorer Version: v28.30.1300 (64-bit)
2) Windows Version: Windows 11 Pro 25H2 (Build 26200.8655)
3) Screen Scaling Percentage: 100% (1920x1080, XYplorer maximized)

WHAT HAPPENS

Copying files in XYplorer with Ctrl+C intermittently makes Windows Explorer (explorer.exe) crash and restart (taskbar/desktop reload). XYplorer itself is completely unaffected and the copy/paste always completes correctly. Plain Ctrl+C / Ctrl+V only - no drag & drop involved.

FREQUENCY / HISTORY

9 explorer.exe crashes logged in the last 30 days (Application log, Event ID 1000), two of them today:
2026-06-08 18:35, 06-11 18:01, 06-11 19:36, 06-23 18:40, 06-24 11:41, 06-30 15:55, 07-06 15:08, 07-07 11:34, 07-07 15:47.
The crashes span two Windows servicing levels (shell binaries 10.0.26100.8457 and .8655), so this is not tied to one specific Windows cumulative update.

CRASH ANALYSIS

I analyzed the 4 available WER minidumps of explorer.exe (LocalDumps) and resolved the stacks against Microsoft's public symbol server. All four dumps show the identical failure; the remaining logged events fault at the same two sites.

Signature: access violation 0xC0000005 (read) in memcpy, called from windows.storage.dll while cloning an ITEMIDLIST that Explorer obtained from the clipboard data object's "Shell IDList Array" (CFSTR_SHELLIDLIST / HIDA). The PIDL size computed by walking the cb chain is far larger than the actual buffer (claimed 39-147 KB vs ~9-64 KB actually mapped), i.e. the ID list appears to lack a proper terminator / has a corrupt cb chain, and the copy runs off the end of the allocation into an unmapped page.

Two crashing entry paths, both fired by Explorer probing the clipboard right after it changes (Win11 command bar updating Paste availability - explains why no user drag is needed):

Code: Select all

Variant A (4 of 4 dumps):
  ucrtbase!memcpy_repmovs                          <- AV: source buffer overread
  windows.storage!ILCloneParent
  windows.storage!SHBindToFolderIDListParent
  shell32!DataObj_GetIDList
  shell32!CFSDropTarget::_CanSourceTransferHIDA
  shell32!CFSDropTarget::_CanMoveCopyHIDA
  shell32!CFSDropTarget::DragEnter                 <- programmatic paste-effect probe (no real drag)
  (COM cross-apartment dispatch: actxprxy/combase/rpcrt4;
   Windows.UI.FileExplorer command bar further down the stack)

Variant B (2 logged events):
  ucrtbase!memcpy_repmovs
  windows.storage!CShellItem::SetIDList
  windows.storage!SHCreateItemFromIDList
  windows.storage!SHGetItemFromDataObject
  (Windows.UI.FileExplorer!CommandBarViewAdapter on the stack)

Example register math from the 2026-07-07 15:47 dump (fully self-consistent):
memcpy total size rbp=0x1E128 (123,176 bytes), source rdx=0x5A239190, faulted at rsi=0x5A242000 (exact page boundary) after copying 0x8E70 (36,464) bytes, remaining rcx=0x152B8. So the walked PIDL claimed ~3.4x more data than the allocation actually held.

HOW I TRIGGER IT

- Select a few dozen up to ~100 files/folders in XYplorer, press Ctrl+C, while at least one File Explorer window is open. Explorer crashes within seconds (its clipboard probe), not every time.
- Paths frequently contain CJK (Chinese) characters.
- Copy source is always XYplorer; copying the same items with File Explorer as source has never crashed here.

NOTES

- Third-party shell extensions are installed (Baidu Netdisk, TortoiseSVN, Google Drive, PowerToys, 360zip), but none of them appear anywhere on the crashing call stack - the parsed data comes from the clipboard data object.
- Not yet tested with a clean default XYplorer configuration.
- The 4 .dmp files (~50 MB each) are available on request, as is a small validator script that checks the on-clipboard HIDA structure offline. Happy to test beta builds or capture more data.

[admin]

Hi, can't reproduce. You might be able to mitigate the issue for you by unchecking Configuration | Other | Shell Integration | Drag and Drop | Extended compatibility for clipboard and drag and drop.

[marksooxx]

Hi, can't reproduce. You might be able to mitigate the issue for you by unchecking Configuration | Other | Shell Integration | Drag and Drop | Extended compatibility for clipboard and drag and drop.

I did what you suggested, and the problem hasn't happened again. Thank you so much!

[daniel_m]

I had Windows Explorer and XYplorer crash infrequently. It was usually cut & paste, and wouldn't crash anything until the right-click for paste. No non-western characters were involved. This bug has been haunting me for a while now.

Curious if this will fix crashes for me too.

[admin]

right-click for paste? If it's the shell context menu that's being called, the culprit is probably a buggy third-party shell extension.

[daniel_m]

It could well be a shell extension. But I only have 4 (Flexible Renamer, RapidCRC, 7Zip, and Windows Defender), that I have had for some years now, before the crashes happened.

Can the Shell IDList Array be NULL, or contain a NULL element because of some timing issue like a file system delay, and then crash XYplorer? Or is there a sanity check for the array?

I am not 100% sure yet, but disabling "Extended compatibility for clipboard and drag and drop" might also have solved my issue with disappearing exe files (https://www.xyplorer.com/xyfc/viewtopic.php?p=229610).

[admin]

I'd need a way to reproduce these things. Otherwise it's very hard to see a potential issue, especially since it seems to be so rare.

[daniel_m]

Ooooookay, I think I managed to replicate the crashes ... and possibly found an iffy Shell IDList Array to be the cause (at the end of this posting).

I wrote a small AutoHotkey V1 script to right-click at a given x y position repeatedly, with a sleep time between clicks. F2 right-clicks at the given x y coordinates of a folder in XYplorer, F3 right-clicks and dismisses the context menu with Esc afterwards to test the Windows desktop, and F1 stops clicking.

To exclude user installed shell extensions, I moved XYplorer (v28.30.2102 x64) into a VirtualBox running Windows 10 (scale at 100%).
A fresh copy of XYplorer crashes in a fresh installation of Windows 10 just like my XYplorer configuration on the host system. Crashes happen when "Extended compatibility for clipboard and drag and drop" (EC) is enabled, which is the default setting in XYplorer. I conducted all experiments copying a folder, but copying/cutting a file probably gets the same result.

How to replicate:
1) Make sure EC is enabled.
2) Right-click and copy a folder.
3) Right click repeatedly on any folder/drive. Use right-click.ahk to automate and accelerate clicking (AutoHotkey Window Spy helps finding the x y coordinates of a folder in XYplorer).
=> XYplorer will crash eventually


Here are my findings:

1) It only takes one copy operation of a folder to trigger a crash after right-clicking on a folder/drive repeatedly.
2) At the fastest click rate with 1 ms pause between clicks, the number of clicks to crash varies between 100 and 10'000, which corresponds to <1 s to 2 minutes. Sometimes, XYplorer does not crash for an hour.
3) When XYplorer does not crash within 2 to 3 minutes, re-launching XYplorer will likely make it crash faster (by chance).
4) When the pause between clicks gets increased to 5 ms, crashes are less frequent. With a 10 ms pause, crashes are infrequent.

5) Copying a folder in XYplorer with EC enabled and then disabling it does still crash XYplorer.
6) Copying a folder in XYplorer with EC enabled can also crash explorer.exe (as Windows File Explorer or as the Desktop) after repeated right-clicks.

7) Copying a folder in XYplorer with EC disabled, will not crash explorer.exe.
8) Copying a folder in Windows File Explorer won't crash XYplorer or explorer.exe.

9) Right-clicking the background of the list view or tree, or a file in the list view, won't crash XYplorer.
10) Having text only in the clipboard won't crash XYplorer.



I monitored the clipboard with InsideClipboard, but did not see a difference in the clipboard content before and after a crash (binary dumps have the same SHA1 hash).
The binary content of CF_HDROP, FileName, FileNameW, and Preferred DropEffect, are the same between Explorer and XYplorer. The Shell IDList Array is different ... and possibly the reason for crashes:

explorer.exe

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  01 00 00 00 0C 00 00 00 0E 00 00 00 00 00 50 00  ..............P.
00000010  31 00 00 00 00 00 23 5D B4 01 10 08 5F 74 65 73  1.....#]´..._tes
00000020  74 00 3C 00 09 00 04 00 EF BE 1B 5D 3D AA 28 5D  t.<.....ï¾.]=ª(]
00000030  D2 14 2E 00 00 00 80 C9 00 00 00 00 0C 00 00 00  Ò.....€É........
00000040  00 00 00 00 00 00 00 00 00 00 00 00 27 6D A2 00  ............'m¢.
00000050  5F 00 74 00 65 00 73 00 74 00 00 00 14 00 00 00  _.t.e.s.t.......

XYplorer

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  01 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00  ................
00000010  68 00 00 00 01 00 00 00 14 00 1F 50 E0 4F D0 20  h..........PàOÐ 
00000020  EA 3A 69 10 A2 D8 08 00 2B 30 30 9D 3A 00 2E 80  ê:i.¢Ø..+00.:..€
00000030  3A CC BF B4 2C DB 4C 42 B0 29 7F E9 9A 87 C6 41  :Ì¿´,ÛLB°).隇ÆA
00000040  26 00 01 00 26 00 EF BE 11 08 00 00 F7 4F 6A C7  &...&.ï¾....÷OjÇ
00000050  C5 97 D5 01 80 F7 48 97 45 3F DD 01 1C 8F FE AC  Å—Õ.€÷H—E?Ý...þ¬
00000060  45 3F DD 01 14 00 00 00 50 00 31 00 00 00 00 00  E?Ý.....P.1.....
00000070  23 5D B4 01 10 08 5F 74 65 73 74 00 3C 00 09 00  #]´..._test.<...
00000080  04 00 EF BE 1B 5D 3D AA 28 5D 52 1E 2E 00 00 00  ..ï¾.]=ª(]R.....
00000090  80 C9 00 00 00 00 0C 00 00 00 00 00 00 00 00 00  ۃ..............
000000A0  00 00 00 00 00 00 27 6D A2 00 5F 00 74 00 65 00  ......'m¢._.t.e.
000000B0  73 00 74 00 00 00 14 00 00 00                    s.t.......

At this point, I had to consult an LLM to make sense of the array structure. This is my understanding of the rabbit whole I fell into:

Offset 0x00 to 0x03 are the cidl, and 1 because one item was copied to the clipboard.

Offset 0x04 to 0x07 are the aoffset[0] that points to the parent PIDL. Explorer points to offset 0x0C, which is the desktop (0x0000). XYplorer points incorrectly to 0x00, which is the cidl containing 0x0100. This is not just wrong, but 0x0100 is invalid for an aoffset[0].

Offset 0x08 to 0x0B are the aoffset[1] that points to the child PIDL. Explorer points to 0x0E, which is 0x50 and the offset for the folder name "_test". XYplorer points to 0x18, which is seems to be a valid structure for "My Computer\Desktop\", which is the parent.

The LLM pointed out that the cidl, aoffset[0], and aoffset[1], would make sense as 64-bit integers, with the aoffsets pointing to the correct data. Apparently, Windows (x64) expects 32-bit integers and terminates XYplorer with exception 0xc0000005 due to invalid data or an invalid pointer. Every right-click on certain targets in XYplorer or Explorer forces Windows to evaluate the invalid Shell IDList Array. I don't know why it takes so many clicks to trigger a crash. Maybe Windows falls back to the CF_HDROP most of the times before parsing the invalid aoffsets. And sometimes it does parse, and fails ...

[admin]

Interesting, thank you! Gimme a little time for this.

[daniel_m]

Damn, I am too tired for ... words ...

I might have to clarify that the 64-bit thing doesn't mean that 4 bytes for cidl, aoffset[0], and aoffset[1], would make sense when interpreted as 64-bit integers, but that cidl, aoffset[0], and aoffset[1], from XYplorer are stored as 64-bit integers, so 8 bytes wide.

That makes the XYplorer 64-bit structure
Offset 0x00 to 0x07 for cidl => 01 00 00 00 00 00 00 00 => 1
Offset 0x08 to 0x0F for aoffset[0] => 18 00 00 00 00 00 00 00 => offset 0x18 as start for parent
Offset 0x10 to 0x17 for aoffset[1] => 68 00 00 00 01 00 00 00 => offset 0x68 as start for child

But Windows reads it as 32-bit structure
Offset 0x00 to 0x03 for cidl => 01 00 00 00 => 1
Offset 0x04 to 0x07 for aoffset[0] => 00 00 00 00 => offset 0x00 as start for parent
Offset 0x08 to 0x0B for aoffset[1] => 18 00 00 00 => offset 0x18 as start for child

[admin]

Should be fixed in next beta.