A Windows feature update can break every custom control call on a UVC camera while the video stream keeps running: the device still enumerates, frames still arrive, and each parameter read or write on its extension unit fails with E_POINTER, 0x80004003. This guide is for engineers who drive UVC extension units through IKsControl::KsProperty from their own driver or SDK. You will confirm the failure from the HRESULT alone, fix it by passing one real argument, prove the fix with a set-and-read-back test, and decide between patching your code and rolling the update back.
The short answer
Pass a bytes-returned pointer, not nullptr. A call shaped like ksControl->KsProperty((PKSPROPERTY)&node, sizeof(KSP_NODE), data, len, nullptr) returned 0 on Windows builds before version 1607. On version 1607, build 14393, the identical call returns -2147467261, which is E_POINTER, 0x80004003: the method can no longer write its bytes-returned count through a null pointer, so it rejects the whole call. Declare a ULONG, initialize it to 0, pass its address, and check the HRESULT and the count. Nothing is wrong with the camera, the cable, the driver package or the USB link. Frames kept streaming in every reported case, and the same one-line change restores reads as well as writes.
Confirm the failure before you touch code
Three signs point at this fault and not at the camera:
- The device enumerates and delivers frames; capture works in any viewer.
- Initialization or the first parameter call fails, and every later SET or GET through the same helper fails with the same value.
- Calls that do not pass through the null-pointer pattern keep working, which is why the stream is unaffected.
Work the HRESULT out once and you will recognize it in any log. Take the decimal value the failing call returned, -2147467261:
- Convert to unsigned 32-bit: 4,294,967,296 - 2,147,467,261 = 2,147,500,035.
- Write it in hex: 2,147,500,035 = 0x80004003.
- Split it the way an HRESULT is laid out: bit 31 set means failure; bits 16 to 26 give the facility, (0x80004003 >> 16) & 0x1FFF = 0, which is FACILITY_NULL; bits 0 to 15 give the code, 0x4003 = 16,387, which is E_POINTER.
Severity set, facility 0, code 16,387: the receiver of your arguments reported an invalid pointer. That is a call-shape fault, raised on the host side before the camera sees anything.
Why the null pointer stopped working
The method reports how many bytes it handled. Its documentation describes the last argument as an output parameter the method fills with the number of bytes it actually stored, and states that when no data is stored the size is zero. That makes a writable address part of the call's contract. A null pointer gives the method nowhere to write, and the stricter argument checking that arrived with version 1607 turns that into E_POINTER instead of quietly tolerating it. The kernel-side form of the same method, documented for callers in ks.h, behaves the same way, so the contract is not specific to the user-mode proxy.
The timing explains a detail worth knowing: on writes, the request could reach the camera before the failure is reported, which is why some parameters kept taking effect even while every call failed. You simply had no confirmation, so confirmation loops retried without end.
Extension units themselves are untouched. They are the standard mechanism a UVC camera uses to expose vendor controls beyond the standard set, defined by the USB Video Class so that a host can discover and drive them generically. What changed is how strictly Windows checks the call, not how the camera exposes its controls.
Apply the fix
You need the source that issues the calls, a rebuild of that binary, and one saved run of the failing initialization for comparison.
- Find every call site that passes nullptr as the last argument of KsProperty. In the reported failure one wrapper function served init, SET and GET, so fixing the wrapper fixed every path at once.
-
Declare the output variable with a type and an initial value:
ULONG bytesReturned = 0;. -
Pass its address as the final argument, keeping your property layout exactly as it was, with the same
KSP_NODE, the same buffer and the same length. - Check the result. Treat 0 as success; the documented return on success is NOERROR, which is 0. Log failures in hex.
- On reads, require a nonzero count too. A 0 return with a count of 0 means nothing was stored, so the read is empty: retry it or fail the step instead of parsing a stale buffer.
- Rebuild and rerun the failing sequence, and confirm the same calls now return 0.
// API names are the documented ones; variable names are this guide's own.
ULONG bytesReturned = 0; // was nullptr before the update
HRESULT hr = ksControl->KsProperty(
(PKSPROPERTY)&node, // your KSP_NODE, filled as before
sizeof(KSP_NODE),
data, // your payload buffer
len, // its length in bytes
&bytesReturned);
if (FAILED(hr))
{
// log hr in hex here; the pre-fix binary shows 0x80004003 on every call
}
Prove the fix with a set-and-read-back test
Pick a control you can write and read with no physical effect. Write a value, read it back, and assert three things: the write returned 0, the read returned 0 with a byte count greater than 0, and the value came back unchanged. On the broken binary the write logs 0x80004003 and the read cannot confirm anything. On the fixed binary both return 0, the read reports a nonzero count, and the value matches.
Then run the full initialization. Every parameter write that previously failed confirmation now succeeds on the first call, which is what removes the retry stalls. That is also the behavior runtime parameter control for exposure and white balance depends on: set live, read back, continue, with no driver reload.
If the calls live inside an SDK
When the failing KsProperty sits inside a vendor SDK you cannot rebuild, your part is a report, not a patch. Send the vendor the OS build, the exact HRESULT 0x80004003 on every extension-unit call, and the fact that streaming still works. The change they need is the same one line, passing the bytes-returned pointer, and a build that includes it removes this failure.
Rolling the update back is a bridge, not a plan. The built-in rollback window closes about 10 days after a feature update; after that, going back means reinstalling the previous build. Once the fixed SDK ships, take it and pin the version: the discipline in edge inference devices and SDK version pinning keeps an update cycle from re-testing your whole station.
Common mistakes
- Fixing only the write path. Reads and queries call the same helper with the same nullptr; fix the helper, not one caller.
- Declaring the variable without initializing it. Start it at 0 so an empty read is distinguishable from stale stack data.
- Reading E_POINTER as a camera fault. The proxy rejects the arguments before any USB control transfer; the camera never saw the call.
- Retrying without an exit. With nullptr in place, success never arrives, so retry-until-success runs all shift. Bound the retries and surface the HRESULT.
- Blaming the device after an unrelated update. A camera that vanishes or loses drivers has a different fault, covered in depth camera RGB and virtual drivers missing after a Windows update.
When it is not this
- A different HRESULT on each call points at the device or the bus, not at your arguments. Argument faults repeat the same code every time.
- GigE cameras fail parameter reads on a different stack after a driver mismatch; the matching sequence is in GigE cameras failing to read a parameter after a driver mismatch.
- Linux hosts report their own kind of control failure, most often controls that list empty because they live on a different node; see V4L2 controls that live on the right node.
- A firmware update that changed device behavior breaks at a different layer again; the pattern in a firmware update breaking a Python vision script is the closest match.
The decision, per case
| What you see | What to do |
|---|---|
| 0x80004003 on every extension-unit call, frames still streaming | Pass a bytes-returned pointer in your code, rebuild, run the set-and-read-back test |
| The same failure, but the call sits in an SDK | Report the build and the HRESULT to the vendor; roll back only as a bridge inside the 10-day window |
| Camera missing or driverless after the same update | Fix enumeration and drivers first; the control calls were never the problem |
| A different HRESULT on every call | Device or bus fault; take hex logs to the vendor with the unit's serial |
Patch the call, keep the OS current, and keep the SDK current: that combination survives the next update as well.
Where to go next
If you are speccing hardware for the next station, remember that a camera driven through an SDK inherits whatever argument discipline the SDK was written with, so one integration test per OS update is worth the hour. The area scan cameras cover standard inspection heads, board-level cameras suit embedded builds, and the 3D sensors cover depth work; the camera finder narrows by interface, resolution and shutter, and the configurator pairs camera, lens and light in one pass. More update-day failure modes sit on the systems topic page. If a control failure survives the fix, send the HRESULT and the build number through the contact page.
Questions
Does E_POINTER 0x80004003 mean the camera is damaged?
No. 0x80004003 is E_POINTER: severity bit set, facility 0 (FACILITY_NULL), code 16,387, meaning a pointer that is not valid. The proxy rejects the arguments before any USB control transfer reaches the camera, and the video stream kept running in every reported case. A damaged device shows up as missing enumeration or dead frames, not as the same HRESULT on every control call.
Why did the same KsProperty call work before the update?
Builds before Windows 10 version 1607 tolerated a null bytes-returned pointer and returned 0 anyway. From 1607, build 14393, the same call returns E_POINTER. The documentation describes the last argument as an output the method writes into, the number of bytes stored, so a writable address is the real contract; 1607 simply began enforcing it.
Can I ignore the error and retry until the write sticks?
Not reliably. In the reported cases some writes did land while the call still failed, so a blind retry can work by luck. But you get no success signal: reads return nothing usable, and a loop without an exit condition spins for the whole run. Pass the pointer and retry only when the HRESULT is genuinely nonzero.
What should the bytes-returned value be after a successful read?
The count of bytes the method stored in your buffer. On a read of an extension-unit control, expect a nonzero count when data came back, and a zero count with a zero return code means nothing was stored, which is an empty read. Treat that pair as a failure and retry or report it, rather than parse a stale buffer.
My camera's controls run through a vendor SDK. What do I change?
Nothing in your code: the null pointer sits inside the SDK. Send the vendor your OS build, the exact HRESULT 0x80004003 on every extension-unit call, and the fact that streaming still works; the fix on their side is the same one-line change. Until a fixed build ships, the only workaround is rolling the update back, and the built-in rollback window closes about 10 days after the update.
Is this why my camera disappeared after the update?
Probably not. This failure leaves the camera enumerated and streaming; only the control calls fail, with the same value every time. A device that vanishes, loses drivers or stops delivering frames after the same update has an enumeration or driver-stack problem, which needs its own fix before parameter code matters again.