Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Dropbox app on Windows 11 intermittently hangs.
Application Affected Dropbox folder and tray application Device Dell Alienware Aurora R2 Operating System/Browser (if using the web) Windows 11 24H2 and now 25H2 v235.4.5905 Question or Issue The Dropbox application has been intermittently hanging on my computer for at least 4 months. I use the app to take photos with my iPhone and regularly notice that Photos from my iPhone are not appearing in my "Camera Uploads" folder on my PC. If I create a file in the Dropbox folder, it shows the two blue arrows but makes no progress. If I right If I right-click on the Dropbox tray icon, nothing happens. If I start task manager and kill all the running Dropbox processes, then use Start -> Dropbox, everything is normal again for a while. Typically, I find it hung about once a day, although it's not after anything in particular that I remember doing -- usually when I go to look for a photo I took, I find it's not there, and the tray icon is non-responsive. I'm only using 1.35% of 2.01TB so space is not a problem. My C drive, which contains the Dropbox folder in my home directory has 273GB free out of 951GB. I believe I am running the latest version of Dropbox. There's another thread From September with a similar report and supposedly an update fixed it. I do also have OneDrive, iCloud Drive, iCloud Photos, running on my computer and the Adobe Cloud as well, although I think they handle sync differently. Any ideas as to how I might resolve this problem?
The Dropbox desktop app on my Windows 11 is stuck "indexing" files.
Application Affected Dropbox app Device Generic gamer computer Operating System/Browser (if using the web) Windows 11 Dropbox App Version (if using the app) 242.4.5815 Question or Issue After Dropbox made me loose a large amount of relevant files, it started to sync files which took overnight. Now it's being the entire day "indexing". After the whole "we keep your files safe" fiasco, I need to know what's wrong with Dropbox and why it keeps indexing files infinitely. Any ideas-solutions?
macOS 26.3 (M4) Dropbox v243.3.6895: CxSupportTool window loop + Chromium 102 renderer abort
Application Affected: Dropbox Desktop (macOS) Device: MacBook Pro M4 Max, 36GB RAM Operating System: macOS 26.3 Tahoe (Apple Silicon) Dropbox App Version: 243.3.6895 (Electron 19.1.9-dropbox.50 / Chromium 102) Subscription: Dropbox Pro Question / Issue Two distinct bugs prevent normal use of the Dropbox desktop client: CxSupportTool diagnostic window launches automatically every 2-12 seconds whenever any Dropbox UI is opened (Settings, tray popup), displaying raw sync engine debug output to the end user. This makes the Settings UI unusable and predates macOS Tahoe. Renderer processes abort on macOS 26 due to a FATAL:logging.cc failure in Chromium 102, causing IPC errors and renderer death. This is macOS 26-specific. Bug 1: CxSupportTool Diagnostic Overlay Reproduction Steps Launch Dropbox normally Click the Dropbox menu bar icon Open Settings/Preferences (or interact with the tray UI) Wait 2-12 seconds A 960x540 window titled "CX Support Tool" appears, showing raw sync engine diagnostics: PhaseInformation, SyncStatus, EngineWaitTracker, PendingSetTracker Pending set count (600-900+ items), capped: true Closing the window does not help - it reappears within seconds The cycle repeats indefinitely, making Settings navigation impossible Observed Behavior The diagnostic window is not a crash dialog - the main process and renderer processes remain alive. The window is a fully rendered BrowserWindow ( cxSupportToolView ) spawned by the Dropbox "journey" system. It displays the output of fetchEngineDebugInfo() , which is internal sync engine state not meant for end users. The issue persists across: Multiple macOS versions (predates Tahoe) Clean reinstalls of Dropbox Clearing all local caches and crash data Root Cause Analysis I extracted and analyzed app.asar and traced the trigger chain: SyncErrorServiceImpl detects sync errors → fetchEngineDebugInfo() IPC call → CxSupportToolController.launchJourney() (module 898 in main.js) → spawnViewWithServices() creates BrowserWindow (960×540) → cxSupportToolView renders engine debug info CxSupportToolController (in main.js module 898) extends BaseUserJourneyController and is registered as: registerUserJourney( UserJourneyType.CX_SUPPORT_TOOL_FLOW, { singleton: true, controllerClass: CxSupportToolController } ) The journey is launched by SyncErrorServiceImpl when the sync engine's pending set enters a "capped" state. Telemetry is tagged under DesktopComponent.SYNC_ERRORS . Why the sync engine is capped: The user's Dropbox folder contains software development projects with node_modules , .git , and __pycache__ directories totaling approximately 965,000 files. These small, numerous files overwhelm the sync engine's pending set tracker, causing it to cap (a circuit-breaker mechanism). The capped state is then interpreted by SyncErrorServiceImpl as a sync error, which repeatedly launches the diagnostic journey. Storing development projects in cloud-sync folders is common. The sync engine should handle large file counts without surfacing internal diagnostics to users. Workaround Applied Set com.dropbox.ignored extended attribute on node_modules (17 dirs), .git (44 dirs), and __pycache__ (86 dirs) to exclude them from sync Patched app.asar to replace CxSupportToolController.launchJourney method body with return{result:0} (same byte length to preserve asar offsets), preventing the diagnostic window from spawning The asar patch is temporary - the auto-updater will overwrite it. Suggested Fixes Do not show raw engine debug info to end users. The CxSupportToolView displays PhaseInformation , SyncStatus , EngineWaitTracker , and PendingSetTracker output - this is engineering diagnostic data with no actionable information for customers. Add rate limiting or debounce to CxSupportToolController.launchJourney() . Currently, when SyncErrorServiceImpl detects a capped pending set, it can launch the journey repeatedly (every 2-12 seconds). Even if the diagnostic window is appropriate in some contexts, it should not spawn in an unbounded loop. Don't treat a capped pending set as a user-facing sync error. A large number of pending files is a normal condition for users with many small files (developers, photographers, etc.). The sync engine's circuit breaker should not trigger a customer-facing diagnostic journey - it should log internally and continue processing. Auto-ignore common regenerable directories. Directories like node_modules , .git , __pycache__ , venv , and build are well-known to be regenerable and contain large numbers of small files. These could be suggested for exclusion or ignored by default when detected, similar to how .gitignore patterns work. Bug 2: Chromium 102 Renderer FATAL Abort on macOS 26 Reproduction Steps Run Dropbox on macOS 26.3 Tahoe Observe stderr output (launch with ELECTRON_ENABLE_LOGGING=1 ) Renderer processes emit: FATAL:logging.cc(144) Failed to init logging: Operation not permitted Renderers abort immediately Main process logs: Error: Render frame was disposed before WebFrameMain could be accessed Root Cause Chromium 102 (used by Electron 19.1.9-dropbox.50) attempts to initialize file-based logging inside the renderer sandbox. macOS 26 tightened sandbox permissions, causing the logging.cc initialization fails with 'Operation not permitted'. Chromium treats this as a FATAL error, which calls abort() and kills the renderer process. The Electron project tracks similar issues with older Chromium on newer macOS (e.g., electron/electron#48311). Workaround Setting CHROME_LOG_FILE=/dev/null before launching Dropbox prevents the FATAL abort: CHROME_LOG_FILE=/dev/null /Applications/Dropbox.app/Contents/MacOS/Dropbox This sidesteps the permission failure by redirecting Chromium's log file. Suggested Fix Upgrade the Electron/Chromium runtime. Electron 19 (Chromium 102) is from June 2022 and EOL. Newer Chromium handles macOS sandbox changes fine. At the very least, logging.cc init should handle permission failures instead of calling abort() . Environment Details Component Value Dropbox version 243.3.6895 Electron 19.1.9-dropbox.50 Chromium 102 macOS 26.3 Tahoe Hardware MacBook Pro M4 Max, 36GB RAM Sync folder ~/Library/CloudStorage/Dropbox.nosync (~82 GB) Sync folder file count ~965,000 files (including node_modules/.git) Pending items at time of issue 600-900+, capped: true Diagnostic Artifacts I collected the following during the investigation and can provide any of it on request: Stderr logs from multiple launch configurations ( ELECTRON_ENABLE_LOGGING=1 , CHROME_LOG_FILE=/dev/null ) Extracted and annotated sections of main.js (module 898 - CxSupportToolController ) Extracted cxSupportToolView renderer and preload scripts apex.sqlite3 Stormcrow configuration (feature flag state) Screenshots of the CxSupportTool diagnostic window Process traces showing the renderer FATAL abort sequence Approaches That Did Not Resolve the Issue Approach Result Clean reinstall of Dropbox The CxSupportTool issue persisted Clearing GPU cache, Electron caches, and saved window state No effect ELECTRON_DISABLE_GPU=1 environment variable Delayed diagnostic window, but it didn't prevent it --disable-gpu , --disable-gpu-compositing CLI flags Crashed the entire application --no-sandbox CLI flag Crashed the entire application Clearing the Crashpad crash dump directory No effect --remote-debugging-port=9222 Dropbox strips the flag; no remote debug access Deleting Stormcrow feature flag database ( apex.sqlite3 ) No effect - rebuilt on next launch Deleting 59 conflicted copies from the sync folder Pending count actually increased temporarily Feel free to get in touch for any additional details or inquiries. Best regards, Ryan [personal information removed per the Community's Guidelines]
My Dropbox app on Windows is stuck indexing for 2-3 days now.
Hello, I am facing an issue with my Dropbox desktop app on Windows where it has been stuck on indexing for the past 2–3 days and no files are syncing. The Dropbox web version is working normally and uploads, transfers, and syncing through the browser are fine. The problem is only in the desktop app, which also does not show indexing progress or remaining files. I have restarted my laptop, uninstalled and reinstalled the app multiple times, cleared the cache, changed the Dropbox folder location, and checked antivirus and security settings, but the issue still continues. Any help or suggestions would be appreciated.Should I make everything online only before moving my Dropbox folder to another drive?
Hi, so I want to move my dropbox folder to another drive with more space. Currently my dropbox have around 500 GB of available offline files. It's a company dropbox so in total it has 6 TB of files. I want to move the dropbox folder to a 2tb drive. I read so many problem about indexing that took forever or other syncing problems, so should I make all my 500gb of available offline files into online only before moving? And can I show all the 6 TB folders on my PC but make it available online only? because last time I tried to show the folder, it automatically tried to sync 6 TB into my PC. I only want to see the folder and it's content but not have it locally stored on my PC.List of not-synced folder when using Dropbox Selective Sync
When using Dropbox Selective Sync how I can see a list or generate a report of the folders I do not see on this device (i.e. I do not sync to this device)? I know in the Dropbox Selective Sync Panel I can click through all the folder and subfolders to find the ones I do not sync, but a list in a text or PDF file would be more helpful when I'm going to recreate the same sync behaviour on another machine.
