| Previous | Next |
| ERROR_ARBITRATION_UNHANDLED | ERROR_MP_PROCESSOR_MISMATCH |
ERROR_CARDBUS_NOT_SUPPORTED
A CardBus device could not start because bridge configuration is unsupported
ERROR_CARDBUS_NOT_SUPPORTED corresponds to Win32 error value documented as: The inserted CardBus device cannot be started because of a configuration error on "%hs". The inserted CardBus device requires resources or bridge behavior that the current firmware, bus driver, or hardware topology cannot provide. This is mainly relevant to legacy notebook and expansion hardware.
Where the result appears in real systems
- CardBus insertion.
- Old PCI-to-CardBus bridges.
- Virtualized legacy devices.
- Systems with disabled or incomplete bridge windows.
Evidence to collect before changing the system
record the device and bridge hardware IDs, BIOS version, assigned resources, and Device Manager status; review SetupAPI.dev.log; compare behavior after firmware settings or bridge-driver updates
Keep the original numeric value, symbolic name, API return path, thread and process identity, and the exact timestamp in one diagnostic record. Those fields prevent later layers from replacing this specific result with a generic failure and make correlation with ETW or Event Viewer practical.
Handling and recovery
Update firmware and chipset drivers, verify that CardBus support is enabled, and remove conflicting legacy resource assignments. If the platform lacks compatible bridge support, use different hardware rather than repeatedly reinstalling the same driver.
Code that receives this result should classify it according to the operation that produced it: completion information, a recoverable environmental condition, or a programming defect. The result classification should be made at the API boundary where the caller still knows the handle, object, flags, and expected state.
What not to infer from this code
This result is a platform or bridge configuration problem, not merely a missing function driver for the inserted card.
Implementation guidance
Preserve this result through logging and telemetry instead of immediately converting it to free-form text. When it crosses an HRESULT boundary, record both the original Win32 value and the converted HRESULT; when it crosses RPC, JSON, or another protocol, include an explicit error-domain field so the receiver does not convert it twice.
A useful automated test for this Win32 error should reproduce the relevant state transition, assert the exact returned value, and verify cleanup after both the normal and exceptional path. The test for this Win32 error should also check that a retry is performed only when the underlying state can genuinely change, because unconditional retries often hide ownership, architecture, power, or resource-negotiation defects.
References
Looking for a different code? Search another status or error code.