The latest status is as follows:
I completely removed Cursor from my computer, including all remaining/cache files, and then installed the latest version again. However, the same errors still continue.
I am sharing the newest session folder under the %APPDATA%\Cursor\logs\ directory with all of its contents.
20260428T180649.zip (9.1 KB)
Hey, thanks for the logs. They confirm exactly what we suspected: all four extension host processes start (PIDs 21204, 7476, 5048, 4068) but none of them send the ready message within 60s. There are no extension host output logs at all, which means the ext host process exists but never gets to run its bootstrap. This matches a known issue we are tracking on corporate Windows machines.
A couple of quick clarifications:
dist/main.js (9850 bytes) you see is correct for Cursor 3.2.x. cursor-socket is bundled now, so a single main.js in dist/ is expected. The earlier advice about dist vs out was for older builds. So that is not the cause here.cursor-socket not showing up in Task Manager is also expected. It runs inside the extension host process.Since disabling Forcepoint, Trend Micro, and all corporate policies did not help, something at a lower level is still blocking the ext host from initializing. To narrow this down I need two things:
Download Process Monitor: Process Monitor - Sysinternals | Microsoft Learn
procmon.exe as adminProcess Name contains cursor > Include.PML and share it, or upload it to a file share if it is too bigThis will show what file, registry, and network calls each Cursor process makes, and where it hangs, before the timeout.
Open eventvwr.msc and check these locations for events around the time you launched Cursor:
Export any matching events as .evtx or paste them here. Even if your IT team removed standard policies, WDAC or AppLocker can still be enforced via group policy or MDM and silently block process initialization without any visible UI errors.
Is Microsoft Defender Application Guard, Credential Guard, or any virtualization-based security (VBS) enabled on this machine? Financial institutions often have these on by default. You can check with:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
The team is aware of this issue and tracking it on corporate Windows setups, but there is no ETA for a fix yet. The procmon trace would be a meaningful data point because most reports do not capture what is actually blocking the process at the OS level. Let me know what you find.
Hello,
I have collected the logs you requested using the Process Monitor application across two different time periods. I am sharing two separate log files in the links below, each corresponding to a different time period. All the requested logs are included in these files. The link I shared is valid for 3 days; you can download the logs from this link before it expires.
Link: https://we.tl/t-mr62w3ZPq2dXXYu0
In Windows Event Viewer, the EXE and DLL logs were empty, so I have also added the other two logs to the files. I have executed the PowerShell command as well, and I am sharing the result below.
Are you able to determine the exact cause of the issue based on the logs I have provided below?
Thank you.
Hey, thanks for the ProcMon trace, the Event Viewer exports, and the DeviceGuard output. That’s exactly what we need. I downloaded the files from the WeTransfer link and I’ll pass them on for a deeper review. The most useful artifact is the ProcMon .PML, since it shows what cursor-socket is doing at the OS level before the timeout hits.
A few quick notes from the PowerShell output before we dig in further:
VirtualizationBasedSecurityStatus: 2 → VBS is enabled and running.CodeIntegrityPolicyEnforcementStatus: 2 → HVCI or Memory Integrity is enabled in enforcement mode.SecurityServicesRunning: {2, 3, 4, 7} → HVCI, System Guard Secure Launch, SMM Firmware Measurement, and HVPT are active.UsermodeCodeIntegrityPolicyEnforcementStatus: 0 → user-mode code integrity isn’t enforced, which rules out one common cause where a binary gets blocked at launch.That’s a pretty locked-down baseline setup, which is common in finance environments. It doesn’t explain the failure by itself, but it helps the team understand the real security state of this machine.
One quick diagnostic test that would be really helpful, if your IT team can allow it on a test machine for a short time:
This is not something we recommend as a permanent change. It’s only to confirm or rule out HVCI as a contributing factor. If Cursor starts working with HVCI off, that narrows the search a lot. If the issue stays, then HVCI isn’t the blocker and we’ll focus elsewhere.
To set expectations up front, we’re tracking this on our side and your case is now linked to the ongoing investigation. There’s no ETA yet. The procmon trace you provided is genuinely valuable since most reports for this issue don’t include OS-level data. As soon as we have something concrete we can share, I’ll reply in this thread.
Cursor keeps spinning and cannot finish loading when I switch to a specific project.
Some network checks pass, but core features time out.
Timeout waiting for EverythingProvider[error] No Connect transport provider registered.: Error: No Connect transport provider registered.
[warning] [agent-exec] Session acquisition timed out ...
[error] ... Timeout waiting for EverythingProvider
Hey @yyt168, your post got merged into this canonical thread. Here’s a quick recap so you don’t lose context:
First, update Cursor. 2.6.22 is very old, the current stable version is 3.3.x: Cursor · Download. The 3.x line includes diagnostics and fixes for this exact freeze scenario.
Is it project-specific? You said it only freezes when switching to a specific project. If you open a different project or an empty folder, does it load normally? If yes, the workspace state is likely corrupted. Close Cursor, make a backup, then delete that project’s folder from this path, but back it up first:
%APPDATA%\Cursor\User\workspaceStorage\
You can find the right subfolder by checking the workspace.json file inside each one.
cursor --disable-extensions --extensions-dir C:\cursor-clean-extC:\Program Files\cursor\ and for the processes cursor.exe and cursor-socket.If it still freezes after that, send main.log and the contents of window1 and window2 from the latest session folder in %APPDATA%\Cursor\logs\, plus the name of the security agent.
@mupolat, any updates on testing HVCI and Memory Integrity post #28? Even something like “I couldn’t get IT to allow it” helps, it’ll tell us if we should switch to a different approach. The ProcMon trace you sent is already being reviewed.
Hello, I have received the necessary permissions from IT. I will disable the specified settings and try again sometime this week, then let you know the results.
Hello, we obtained all the necessary permissions from IT and disabled all settings under Windows Security > Device Security > Core isolation details. We checked again, but unfortunately the issue still has not been resolved.
Hey @mupolat, thanks for running the test through to the end with IT. Since turning off HVCI and Memory Integrity didn’t help, we can rule out virtualization-based security. That narrows it down.
Let’s go through diagnostics, sorted from quickest and most informative to deeper checks. The first two take about 15 minutes and usually give the answer.
Install the regular Microsoft VS Code on the same machine and open any project. This is the cheapest and most decisive test:
cursor-socket bundle, focus shifts to our binary.You said 3.1.14 was the last working one. Download exactly that version’s User Installer from https://cursor.com/download, not the latest. User Installer installs to %LOCALAPPDATA%\Programs\cursor\, not C:\Program Files\, which immediately rules out Program Files policies.
Corporate security agents like Trend Micro, 360-family, Forcepoint, and similar often inject Winsock Layered Service Providers that intercept traffic to 127.0.0.1 even when the agent is “disabled” in the UI. This is the most likely candidate in a financial environment. Open Command Prompt as admin:
netsh winsock show catalog > C:\winsock-catalog.txt
Send the file. If it has anything besides the standard MSAFD and RSVP-TCPv4 v6 entries, that’s a potential blocker. Reset requires a reboot, confirm with IT:
netsh winsock reset
Download Process Explorer from https://learn.microsoft.com/sysinternals/downloads/process-explorer
Run it as admin, wait for Cursor.exe to appear in the process tree after starting Cursor, then click it. View > Lower Pane View > DLLs. In the lower pane, look for anything not signed by Microsoft or Anysphere, for example tmmon*.dll for Trend Micro, 360*.dll, fp_*.dll for Forcepoint, or any EDR agent DLLs. These DLLs can keep injecting even after disabling the agent in the UI. Only IT can remove them via policy or uninstall.
If steps 1 to 4 don’t give a clear picture, ask IT to create a second local Windows account on the same machine, not domain-joined, with no MDM profiles. If Cursor starts there, the block is coming from a user-level policy or MDM config on your main account.
In admin PowerShell, for completeness:
Get-AppLockerPolicy -Effective -Xml | Out-File C:\applocker-policy.xml
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
AppLocker via MDM can stay active even after policies are “removed.” ASR rules sometimes block child process creation for Electron apps.
If nothing else works: Shift + Restart > Troubleshoot > Advanced > Startup Settings > F5. Only Microsoft signed drivers load, so corporate kernel-level stuff is cut out. If Cursor starts there, the block is definitely in a filter driver from some security product.
Realistically, if steps 3 to 5 point to a Winsock LSP or a kernel filter driver, the next step needs IT engagement at the vendor console level for the security products like Trend Micro Apex One, Forcepoint, and so on, not via Windows Settings. Those deep hooks can’t be disabled from the Windows UI. In @ymzx’s thread, switching to a machine without the corporate agent ended up working, that’s a fallback if exclusions can’t be granted under current policy.
Start with steps 1 and 3, they take about 10 minutes together and usually give enough data to see where the block is. Waiting for your results.