Excel 2021 freezes when "@" or "drag-drop" blocker is used, but only on local console login, not via rdp

[Allard]

Hi, we're running an application which blocks the use of "@" and drag and drop of characters.
This works perfectly fine on most systems, but some machines experience freezing of excel in case a user is locally logged in. None of this happens when logged in via rdp on that same machine.

Any clues where to start searching? (We did try not running the blocker, that solves the issue but is not allowed by company policy )

 

[ChatGPT]

Hi Allard — the RDP vs local console difference is the key clue. I’d start by assuming the blocker is interacting differently with the local input/graphics stack than it does with RDP.
Most likely areas:

Likely causes to investigate​

1. Keyboard/mouse hook deadlock
   • If the blocker uses WH_KEYBOARD_LL, WH_MOUSE_LL, raw input, UI Automation, or window subclassing, it may be blocking Excel’s UI thread.
   • The @ key is meaningful in modern Excel formulas, so Excel may be doing extra parsing/auto-complete work when the blocker intercepts it.
   • Drag/drop in Excel uses OLE/COM-style message handling, so a synchronous “blocker” can easily cause a hang if it waits on Excel while Excel waits on the blocker.
2. Different behavior under RDP
   • RDP input is not identical to local keyboard/mouse input.
   • Some hooks see RDP-generated input as injected/remote.
   • Clipboard and drag/drop are also mediated differently through rdpclip.exe.
   • This can explain why the same machine behaves normally over RDP.
3. Graphics/GPU path
   • Local console uses the real GPU/display driver.
   • RDP often uses a different rendering path.
   • Excel freezes that only happen locally are often worth testing against GPU acceleration/display driver/scaling/multi-monitor differences.
4. Excel add-ins or DLP/security tooling conflict
   • If the blocker is company-mandated, there may also be endpoint security, DLP, clipboard-control, or accessibility-monitoring software hooking the same events.

---

Where I would start​

1. Confirm whether Excel itself is clean​

1. Log in locally to an affected machine.
2. Press Win + R.
3. Run:

excel.exe /safe

1. Test the @ blocker and drag/drop blocker again.
2. If the freeze disappears, check Excel add-ins under:

File > Options > Add-ins

1. Test both COM Add-ins and Excel Add-ins one by one.

Expected result:
If Safe Mode works, the issue is likely a conflict between the blocker and an Excel add-in/startup component.

---

2. Test graphics acceleration/local display path​

On an affected machine:

1. Update or temporarily roll back the GPU driver.
2. Test with only one monitor attached.
3. Test with display scaling at 100%.
4. If available in your Excel build, disable hardware graphics acceleration.
5. Alternatively test this registry setting:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Graphics
DWORD: DisableHardwareAcceleration = 1

1. Restart Excel and test again.

Undo:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Graphics
DWORD: DisableHardwareAcceleration = 0

Or delete the value.
Create a restore point first if you are pushing registry changes broadly.

---

3. Capture a hang dump while Excel is frozen​

This will probably give you the fastest answer.

1. Reproduce the freeze locally.
2. Open Task Manager.
3. Go to Details.
4. Right-click EXCEL.EXE.
5. Select Create dump file.

Or use Sysinternals ProcDump:
procdump -ma -h excel.exe C:\Dumps\excel-hang.dmp
Then inspect the dump in WinDbg and look for threads waiting inside:

EXCEL.EXE
the blocker DLL/process
OLE32
USER32
UIAutomationCore
graphics/display driver modules
clipboard/drag-drop handlers

If you see Excel waiting on the blocker, or the blocker waiting on Excel via SendMessage, COM, UI Automation, or clipboard/OLE calls, you’ve found the conflict.

---

4. Compare local vs RDP processes/modules​

On the same machine, same user, same workbook:

1. Run the test locally and over RDP.
2. Use Process Explorer.
3. Compare loaded DLLs inside EXCEL.EXE.
4. Check whether the blocker injects a DLL into Excel locally but not over RDP.
5. Check whether endpoint security/DLP modules are loaded only in the local-console case.

This is especially important if the blocker is implemented as an injected DLL or global hook.

---

5. Ask the blocker vendor/dev team these specific questions​

If this is an internal or third-party blocker, I’d ask:

1. Does it use low-level keyboard/mouse hooks?
2. Does it inject into Office processes?
3. Does it call SendMessage/COM/UI Automation from inside a hook callback?
4. Does it treat LLKHF_INJECTED or RDP input differently?
5. Does it block Excel drag/drop by intercepting OLE/clipboard messages?
6. Is there a known Office/Excel exception mode?
7. Is there a supported policy-based way to block this instead of live-hook interception?

Important: Hook callbacks should return quickly. A blocker that performs synchronous checks against Excel from inside the input path can easily hang Office.

---

My best guess​

The strongest suspicion is a deadlock between Excel and the blocker’s local-console input/drag-drop hook. RDP avoids it because the input, drag/drop, graphics, and clipboard path are different.
The most useful next artifact would be a hang dump of EXCEL.EXE while frozen, plus knowing whether the blocker injects a DLL into Excel. That should tell you whether this is Excel waiting on the blocker, the blocker waiting on Excel, or a display/driver path issue.