The viewer starts, the sensor has power, and the depth SDK dies before it lists a single camera. The message names the context-creation call — ending in something like failed to convert special folder: errno=42 — and says nothing about cables or optics. That is the clue. The SDK builds its context before it touches the sensor, so this crash lives in the host PC, not in the 3D camera. Three causes cover nearly every context-creation failure on a Windows station PC: a settings file emptied by an unclean shutdown, a user profile path the SDK cannot convert, and libraries from two SDK versions mixed on one machine. Work through the tests below and the cause is named — and usually fixed — inside ten minutes.
What the error is telling you
A context is the SDK's runtime object: loaded libraries, configuration, logging and device handles. Every SDK creates it on launch, before it enumerates any sensor. To build it, the SDK asks Windows for the known folders it needs — the user profile, the per-user application-data locations — converts those paths into the string form it uses internally, and parses its own settings file.
failed to convert special folder: errno=42 means one of those folder reads, or its conversion, failed. The error fires in the first 1-2 seconds of launch and always before a serial number appears, which tells you the sensor has not been contacted yet: it is untested, not broken. That single fact decides the order of work — settings file first, account path second, library set third, hardware last.
Cause 1: a settings file emptied by an unclean shutdown
Most SDKs keep per-user settings — window layout, last selected device, processing parameters — in a JSON file under the logged-in account's application-data folder. When a session ends badly, a power cut, a blue screen, a forced kill from Task Manager, the file can be left at 0 bytes or truncated mid-object. The next launch parses that file as part of building the context, and the SDK dies before anything else happens.
The test takes one minute. Find the JSON file named for the SDK in the account's AppData folders and look at its size. A healthy file is 1-4 KB of readable text. Zero bytes, or a tail that stops partway through an object, confirms the cause.
The fix: close every process the SDK runs, rename the file so you keep it for diagnosis, and launch again. The SDK writes a fresh default file and the context creates normally.
An unclean shutdown damages more than settings — recordings are the usual other victim, as covered in unplayable camera recording file after an unclean shutdown. Nor is this failure mode unique to vision software: the same crash-and-recover pattern appears when a viewer crashes on a corrupt log file, and when a runtime fails on a corrupted runtime database context. In all of these the recovery is identical: find the per-user file the tool reads at startup, rename it, relaunch.
Cause 2: a profile path the SDK cannot convert
Windows builds the per-user folder paths from the account name. An account named with accented or non-Latin characters produces profile paths that some SDK builds fail to convert — the folder lookup succeeds and the conversion step returns the errno you see in the message. Sites that run localized account names hit this without warning: the tool has simply never started on that station before.
Test it in five minutes. Launch the same viewer as administrator, or as a different user, under a local account whose name uses ASCII characters only. Windows can start an application as another user; on Windows 11 the entry is added to a shortcut's right-click menu from the shortcut's properties. If the context creates under that account and fails under the original one, the profile path is the cause.
Make it permanent with a dedicated runtime account — for example vision_runtime, 14 characters, letters and an underscore only — and run the station software under it at every boot. Renaming an existing account does not rename its profile folder, so a new account is the reliable route, not a rename.
Cause 3: two SDK versions on one machine
The third pattern shows up after an update. An SDK's runtime libraries can end up duplicated: the old release left files in the application directory or on the PATH, the new release loads next to them, and the context assembles itself from code of two vintages. The failure lands at startup because that is when the libraries initialize.
A related case is a defect in the SDK itself: one release shipped with an uninitialized settings object in the context-creation code path, the vendor corrected it in a later build, and machines still running the broken build crash no matter what the file system holds. Release notes are the source of truth here — match your installed version against them.
The fix is one clean release. Uninstall every copy, delete leftover runtime files from the application directory, and install a single current build taken from the camera vendor's own download source or its distributor — never a copy from a shared network folder. Library faults beyond the context read the same way: the camera SDK bitness errors behind a Python wrapper ImportError come from the same host-side stack, and SDK and firmware alignment after a header version mismatch is the same discipline applied to the device side.
Three launches that isolate the fault
Run the tests in this order; each launch that behaves differently names a cause.
- Launch under a clean account. Use a local account with an ASCII-only name on the same PC. If the context creates, the original account's profile path or its settings file is at fault — go to step 2 to separate the two.
- Rename the settings file under the original account. If the context now creates, an unclean shutdown corrupted the file; check how the last session ended before trusting the station again.
- Run the same viewer on a second PC. Same version, camera attached. If it works there, the first PC's library set is mixed or stale: uninstall, clean, reinstall one release. If it fails on both PCs with the same message, match the installed version against the vendor's release notes for a fixed context bug.
If startup failures keep returning after all three fixes, the startup sequence itself needs diagnosis — diagnosing startup errors after a crash covers that case. Note where each failure sits: a message before enumeration is host-side, while a clean context that finds no sensor has moved the question to the hardware, which is the next section.
When the context is fine and the sensor is still missing
Once creation succeeds and enumeration returns nothing, the fault moves to the device side: power budget, cable, port and the driver stack. Swap the cable first — it is the cheapest test and the most common fix. On networked depth cameras, a parameter read failure at this stage points at driver and firmware alignment rather than the context, as in GigE camera failed to read parameter: fix the driver mismatch.
The logic is identical for every sensor class in the rack. A ToF sensing camera, a projected structured-light 3D camera and a multi-DOE speckle structured-light camera for volume measurement are all enumerated only after the context exists, so a context crash can never be blamed on any of them.
- Type
- Stereo / structured light
- Type
- Depth / ToF camera
If you are qualifying a station instead of repairing one, the camera finder filters depth sensors by type and interface.
Worked example: a ten-minute recovery
Monday 06:40, palletizing cell: the depth viewer fails at launch with failed to convert special folder: errno=42. Friday 21:14 the cell lost power during a write.
- The Windows recovery record shows the unexpected shutdown at 21:14 on Friday — an unclean end to the last session.
- The SDK's settings JSON sits under the operator account's AppData folder. Healthy size for a file of this kind: typically 1-4 KB. Measured size: 0 bytes. Zero bytes against the kilobytes it should hold means the file holds nothing, so the parser dies on its first read — that is the cause.
- Close every SDK process, add a
.baksuffix to the file, relaunch. The context creates in under two seconds and the sensor enumerates with its serial. - Close the second cause while you are there: the operator account name uses non-Latin characters, so create
vision_runtime(14 ASCII characters), give it rights on the station software, and set the shortcut to launch as that user. - Reboot once and launch: context created, no message, sensor listed.
Total repair time: about ten minutes. A reinstall would have taken 30-60 minutes and fixed nothing, because per-user files and duplicate libraries survive it. Hardware touched: none.
Five habits that keep the crash away
- Shut down cleanly. Close the viewer and stop acquisition before cutting power or rebooting; a small UPS on the station PC pays for itself the first time a write lands mid-power-cut.
- One SDK release per PC. After an update, uninstall the old release and search the application directory for its leftovers before the next boot.
- One naming rule for accounts. An ASCII-only runtime account on every cell, created when the PC image is built, removes the profile-path cause for good.
- Keep a known-good settings copy. A copy of the settings file in the cell's backup turns recovery into a restore instead of a diagnosis.
- Check the file after any crash. One size check in AppData tells you in a minute whether the next launch will fail.
Where to go next
If all three launches fail with the same message on a clean library set, send the exact error line, the SDK version and the account name to the applications team through the contact page — that is enough for a second pair of eyes to pick up the case. If the fault is pushing you toward new depth hardware instead, the 3D sensors range covers laser profilers, structured-light cameras and ToF sensors, and more depth-camera guides sit in the Learn hub.
Laser profilers and stereo 3D cameras
170 models · from $699.00Questions
Why does the error appear before the camera is even detected?
Context creation runs first: the SDK loads its libraries, reads Windows profile and application-data folders and parses its own settings file, and only then enumerates sensors. A failure in any of those reads stops the SDK at startup, so the message says nothing about the sensor. Treat it as a host-PC fault and work through the settings file, the account path and the library versions before touching the camera.
Can non-Latin characters in a Windows account name really stop a vision SDK?
Yes. Windows builds the profile path from the account name, and the SDK converts those special folders to the string form it needs at startup. Some builds fail that conversion when the path contains accented or non-Latin characters. Launching the same viewer under a local account with an ASCII-only name is the five-minute test; if the context creates there, move the station software to that account permanently.
Where does the SDK keep its settings file?
In the per-user application-data folders Windows keeps under AppData (the Local and Roaming locations), or occasionally in the tool's own install folder. Look for a JSON file carrying the SDK's name. A healthy file is a few kilobytes of structured text; 0 bytes or a tail that stops mid-object means an unclean shutdown corrupted it. Rename it, relaunch, and the SDK writes fresh defaults.
Should I just reinstall the SDK?
Not first. Per-user files and duplicate libraries usually survive a reinstall, so the same crash returns and you have spent the better part of an hour. Rename the settings file and test under a clean account before anything else. Reinstall only when the library set is mixed or the vendor's release notes list a fixed context bug — and take the installer from the camera vendor or its distributor, not a file share.
Can this crash damage the 3D camera?
No. The context fails before the SDK opens any device, so the sensor never receives a command during the fault. Once the context creates and enumeration still finds nothing, the camera becomes a suspect — then check power, cable, port and the driver stack. A context-creation error alone is never evidence of a failed sensor.
How do I stop the crash coming back on a production line?
Close the viewer and stop acquisition before cutting power, and put a small UPS on the station PC. Pin one SDK release per machine and remove old versions after updates. Standardize an ASCII-only runtime account for station software across cells, and keep a known-good copy of the settings file in the cell's backup so recovery is a file restore instead of a diagnosis.