Hang at "QGIS Ready!" Splash Screen Caused by Unreachable Mapped Network Drives #65062
Description
What is the bug or the crash?
When launching QGIS, the programme hangs indefinitely at the "QGIS Ready!" stage of the splash screen. The issue persists even when generating a completely fresh user profile and when the machine is completely air-gapped from the internet. The root cause is the QGIS Browser panel (or underlying Qt network/file system manager) waiting on Windows OS-level polling of mapped network drives that are currently disconnected or unreachable.
Steps to reproduce the issue
Map a network drive (e.g., Z:\ or X:) to a central server or corporate network.
Disconnect the machine from that network (e.g., travelling from a primary office to a remote field site without active VPN access).
Ensure the mapped drive shows as disconnected in Windows File Explorer (typically indicated by a red 'X').
Launch QGIS.
The splash screen processes extensions and core plugins normally, but hard-locks indefinitely once it displays "QGIS Ready!".
Workaround / Resolution
Forcefully disconnecting the unavailable drives via Windows File Explorer or using the Command Prompt (net use * /delete /y) immediately resolves the hang, allowing QGIS to finish booting.
Expected behaviour
QGIS should gracefully timeout or bypass unreachable OS-level mapped directories during startup, rather than locking the main application thread and freezing the boot sequence.
Versions
| QGIS version | 3.44.7-Solothurn |
| QGIS code revision | ea262bc5 |
| Libraries | |
| Qt version | 5.15.13 |
| Python version | 3.12.12 |
| GDAL version | 3.12.1 (Compiled) 3.12.2 (Running) — Chicoutimi |
| PROJ version | 9.7.1 |
| EPSG Registry database version | v12.029 (2025-10-03) |
| GEOS version | 3.14.1-CAPI-1.20.5 |
| SQLite version | 3.50.4 |
| PDAL version | 2.9.0 (Compiled) 2.10.0 (Running) |
| PostgreSQL client version | 17.3 |
| SpatiaLite version | 5.1.0 |
| QWT version | 6.3.0 |
| QScintilla2 version | 2.14.1 |
| OS version | Windows 11 Version 2009 |
| Active Python plugins | |
| assets | 0.8 |
| autoSaver | 2.9 |
| basemaps | 1.3 |
| changeGpkgPath | 1.0.1 |
| coordinate_capture | 0.2 |
| FreehandRasterGeoreferencer | 0.8.3 |
| Generalizer3 | 1.0 |
| GeorefExtension | 3.0.8 |
| geo_trace | 0.1 |
| LAStools | 2.2.0 |
| LiveMeasure | 0.1.0 |
| mapswipetool_plugin | 1.3 |
| mmqgis | 2024.11.8 |
| ORStools | 1.10.0 |
| OSMDownloader | 1.0.3 |
| pluginbuilder3 | 3.2.1 |
| processing_saga_nextgen | 1.1.0 |
| ProcessX | 1.7.1 |
| Qgis2threejs | 2.8 |
| QuickOSM | 2.3.2 |
| quick_map_services | 0.21.2 |
| sgtool | 0.2.18 |
| slyr_community | 6.0.0 |
| tomofast_x_q | 0.2.9 |
| wbt_for_qgis | 1.0.9 |
| whitebox_workflows_for_qgis | 1.2.6 |
| db_manager | 0.1.20 |
| grassprovider | 2.12.99 |
| MetaSearch | 0.3.6 |
| processing | 2.12.99 |
Supported QGIS version
- I'm running a supported QGIS version according to the roadmap.
New profile
- I tried with a new QGIS profile
Additional context
Additional context
This bug is particularly disruptive for field-based workflows where hardware frequently transitions between stable office networks with mapped infrastructure and offline or highly restricted remote networks. The lack of an error dialogue makes it difficult to diagnose, as users typically assume a corrupted profile or plugin is at fault.