GenICam XML schema validate assertion failed? The camera is fine

Your test run prints a schema assertion twice, a Genicam FAILED verdict, and then a sensor size read of 1920 × 1200 from a camera that captures just fine. That combination is not a contradiction: it is two separate faults stacked in one output. This guide gives you the decision rule for the GenICam XML question, decodes each line of that output, and fixes the assertion your own program throws when it calls a feature function on a device handle that never opened. Work through the sections in order and the camera either clears itself or hands you the exact failing stage.

The decision first: is the XML really broken?

Apply one rule and most of the confusion disappears: if any feature read returns correct values, the XML was downloaded and parsed. Reading the sensor size as 1920 × 1200 requires the feature tree, and the feature tree can only exist if the document arrived complete and parsed cleanly. A validator that never built its own check context cannot pass or fail anything, so its FAILED verdict is not evidence about your camera.

So commit. On an output where the sensor size read comes back correct, treat the camera's XML as healthy. Treat Genicam: FAILED Invalid Genicam XML data as a limitation of the test tool's schema setup, and treat the later assertion in your own program — ARV_IS_DEVICE (device) — as a bug in your code, not in the camera. Only when feature reads start failing too does the XML itself become the suspect.

How the XML gets from the camera to your program

A GenICam camera describes every feature it offers — exposure time, gain, width, payload settings — in an XML description file. On a USB3 Vision or GigE Vision camera that file lives inside the device itself, and the library downloads it over the control channel when you connect. The parser turns the document into a feature tree, and every node in that tree carries the register address your reads and writes use. When only the remote device carries the description, the GenTL node maps article on XMLs that exist only on the device shows how that case resolves.

Schema validation is a separate and optional step: it checks the document against the official GenICam schema for conformance. Parsing and validation fail at different layers. A document that cannot be parsed gives you no feature tree at all, and every read fails. A document that parses but breaks a schema rule still works in practice. When a parse really fails, the cause is concrete — the GenICam XML UTF-8 encoding fix walks one genuine parse failure with a decode error.

What each line of the failing output means

Decode the output line by line:

• arv_xml_schema_validate: assertion 'schema->priv->valid_ctxt != NULL' — an internal precondition inside the validator. Its own validation context is NULL, so the check cannot execute. The message describes the test tool, not your camera.
• Genicam: FAILED Invalid Genicam XML data — the verdict the tool prints after that aborted check. It can only repeat what the validator reported, and the validator reported nothing, because it never ran.
• Sensor size read: 1920 1200 — a feature read through the parsed tree. Two register reads returned the values the camera holds, so download, parse and register IO all worked.
• arv_device_get_float_feature_bounds: assertion 'ARV_IS_DEVICE (device)' — a different layer entirely. This is the type check on the device handle your own code passed in when it called arv_camera_get_exposure_time_bounds; it fires when the handle is NULL or already closed.

The first three lines belong to one story: a validator without its schema context. The fourth belongs to your program, and it is the one that needs fixing.

Worked example: a USB3 camera that captures but fails the schema test

Inputs (from the case): a USB3 Vision camera on Linux; the test tool arv-test-0.6 prints the arv_xml_schema_validate critical twice, then Genicam: FAILED Invalid Genicam XML data, then Sensor size read: 1920 1200; capture attempts succeed; later, your own program calls arv_camera_get_exposure_time_bounds and gets the ARV_IS_DEVICE (device) critical.

The rule in words: a feature read needs a node address, a node address needs a parsed XML document, so any correct feature read proves the document parsed. A schema check whose context is NULL validates nothing, so its FAILED verdict cannot outrank the read.

The evaluation, written out:

1. Sensor size read: 1920 1200 is two register reads through the feature tree. Neither 1920 nor 1200 is a placeholder: 1920 × 1200 = 2,304,000 pixels, a coherent sensor geometry the camera reports on request.
2. For those reads to run, the parser must have built nodes for width and height and attached their register addresses. Tree exists, therefore the XML arrived complete and parsed.
3. The validator's precondition fired before any validation ran, so the FAILED verdict describes a check that never executed. The two identical critical lines carry one single fact: no schema context, no verdict.
4. The bounds call failed on the handle, not on the camera — the camera side had already demonstrated working reads in step 1.

Result: the camera passes at the XML layer. The fault to chase is the NULL device handle in the calling program.

Decision and threshold: if at least one feature read returns correct values, declare the XML healthy and stop debugging it. If feature reads fail as well, the XML becomes the suspect and the next section but one is yours. If reads pass but your own calls assert, the bug is in your handle discipline, and the section after this one is yours.

Fixing the ARV_IS_DEVICE assertion in your own code

Causes in order of probability:

1. The connect or create call failed and returned a NULL or unusable handle; your code stored it and called a feature function anyway.
2. The camera object was closed or destroyed earlier in the program, and the stale handle was reused.
3. Another program holds the camera, so your open could not complete. The pattern is the same across interfaces; the GigE camera exclusive-control open failure article shows the diagnosis on GigE Vision, and it transfers directly to USB3 Vision.

Run four steps:

1. Stream with arv-viewer first. If the viewer shows live frames, the camera, cable and driver are fine and the bug is inside your program's open path.
2. Turn on the library's debug logging and rerun your program:

export ARV_DEBUG=all:3
./your_program

Read the log from the open stage onward; the stage that fails names itself. When the open fails before your code ever gets a handle, the camera failed-to-initialize start sequence fix covers the order-of-operations mistakes behind it. 3. Branch on the handle: make the return value of your create or open call decide what happens next. On NULL, print the library error and leave the function — never fall through to arv_camera_get_exposure_time_bounds. 4. Close exactly once, in one place, and reopen after an error instead of reusing the dead handle.

Prevention is one habit: no feature call without a checked handle in front of it. If the bounds call is your first call after a clean-looking open and it still fails, check feature discovery itself — the GenICam exposure feature discovery article covers attributes that never appeared in the tree.

When the XML really is the problem

The signature is simple: feature reads fail too. Then work two causes.

Slow-link truncation. A USB3 Vision camera belongs on a SuperSpeed link of about 5 Gbit/s. If it falls back to USB 2.0 high speed, everything funnels through 480 Mbit/s — roughly a tenth of the bandwidth — and the XML download can stop part-way, handing the parser a shortened document. Read the negotiated speed in the debug log before anything else, then swap in a SuperSpeed-rated port and cable. Embedded boards add their own fallback traps; the USB3 camera fallback troubleshooting guide for an embedded Linux board walks that variant.

Malformed content. A document that arrives complete but breaks at parse — an encoding error is the classic — surfaces as tree errors such as a feature that does not exist; the GenICam node-not-existing diagnosis covers that error family. Content faults and streaming faults are separate layers too: if features read fine but the image comes up grey or dead, follow the camera works in setup but grey image at runtime path instead.

A camera whose internal XML was damaged — power loss during a firmware update is the usual way — needs the vendor's own recovery procedure. Ask through that vendor's support channel before writing the camera off.

Checks before you blame the camera

Work this list and you end either with a working camera or with a named failing stage:

• One feature read returning correct values — record it; it is your evidence the XML loaded.
• arv-viewer streaming frames — proves cable, port, driver and camera in one test.
• A captured ARV_DEBUG=all:3 log — names the failing stage for you and for support.
• Negotiated USB speed at SuperSpeed, roughly 5 Gbit/s, not 480 Mbit/s high speed.
• A NULL check between every open and every feature call in your program.

If the evidence finally lands on the camera, replace it deliberately: browse the area scan cameras range, narrow the field with the camera finder, or start the configurator at the camera step. To read a specific log with someone, contact the applications team, and for more fixes at this software layer the systems topic page collects the rest.