GigE configurator tool admin rights: fix the Windows error

You launch the GigE configurator and it stops before the first window opens: a message saying administrator rights are required, even though your account belongs to the Administrators group. Nothing is wrong with the account. Three of the tool's jobs — writing Windows firewall rules, changing the network adapter's IPv4 settings, loading a packet-level driver — need an elevated process, and Windows hands an administrator account a filtered token until something runs elevated. What follows is the launch that works, the firewall rules worth writing by hand, the subnet arithmetic behind most empty camera lists, and a decision for each case, including how operators on standard accounts get their cameras configured without weakening the PC.

Why the tool checks for elevation

A GigE Vision camera takes its commands over plain UDP, and sending that traffic needs no special rights. The demand comes from what the configuration tool does around the traffic:

• Firewall rules. The tool adds its own allow rules on first run. Writing to the Windows firewall requires an administrator process; a standard account cannot add an inbound UDP rule.
• Adapter changes. The tool rewrites the NIC's IPv4 address to place the PC on the camera subnet. Editing adapter properties is an administrator operation.
• Filter drivers. Tools that must reach a camera with no valid IP yet load a capture driver. Driver loads are kernel operations and always elevated.

So the check exists because the tool edits the PC, not because the camera demands privileges. Under UAC, an administrator logon holds two tokens: processes started normally receive the filtered one, and running as administrator swaps in the full one. The tool tests the token, not your group membership — which is exactly why the error appears even though you hold admin rights. Open a command prompt and run whoami /groups | findstr "S-1-16": S-1-16-8192 means the filtered token, S-1-16-12288 the elevated one.

The two-minute fix

1. Right-click the tool's executable or its shortcut and choose Run as administrator; accept the UAC prompt.
2. When the tool offers to add its firewall exception, accept — that is the elevated write it wanted from the start.
3. Set the NIC's IPv4 address for the camera subnet and write the camera's persistent IP.
4. Close the tool and start it normally. If it opens and lists cameras, the elevation demand was one-time setup.
5. If it still refuses to start unelevated, it self-checks at every launch. Right-click the shortcut, open Properties, then Compatibility, and set Run this program as an administrator once.

The firewall rules worth writing

GigE Vision control traffic, GVCP, runs on UDP port 3956 in both directions. The image stream, GVSP, uses a port negotiated per camera at connect time, commonly 50000 upward, so a fixed port list cannot be written in advance — a program rule for the tool covers both. When you drive cameras from your own code instead, write the control rule by hand:

netsh advfirewall firewall add rule name="GigE Vision GVCP" dir=in action=allow protocol=UDP localport=3956 profile=any

The profile=any part is the one people drop. Windows classifies unidentified networks — and a camera NIC with no gateway is unidentified more often than not — as Public, where a Private-only rule exists and still blocks. That produces the classic pattern where ping works and discovery returns nothing, which GigE Vision camera firewall: ping works, discovery fails walks through in full. If cameras are listed but images never arrive, the cause is usually packet size rather than rights: set the GigE camera packet size before starting acquisition gives the numbers, and the GigE Vision firewall troubleshooting walkthrough covers both directions of the rule set.

The subnet arithmetic behind an empty camera list

The most common "tool starts, no cameras found" cause is not rights at all. The PC and the camera must land on the same network once the subnet mask is applied:

A camera carrying the persistent IP 192.168.1.50 is invisible to a PC at 192.168.0.10/24, because the masked addresses differ in the third octet. Fix either side: set the NIC to 192.168.1.10/24, an elevated one-time change, or use the tool's Force IP function to push the camera onto 192.168.0.50. Force IP is a broadcast write and takes effect without a camera reboot.

A camera straight from the box self-assigns a link-local address, 169.254.x.y, and answers there. A NIC fixed at 192.168.x.y never sees it, so give the adapter a 169.254 address for first contact, then write a persistent IP and move both ends onto your production subnet. Out of the box, every GigE camera behaves this way, including the 6 MP GigE area scan camera shown below.

Screw the connectors home while you are at it: a loose RJ45 produces the intermittent discovery dropout that everyone first blames on rights or drivers. The LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks, and the LS-CBL-0117 gives a locked RJ45 pair at 15 m.

When the error persists after elevation

Work this list in order; each item has a test that takes under a minute.

1. Public profile. Open Windows Settings and read the network location for the camera adapter. Public means your rules must carry any-profile scope — the netsh line above already does.
2. Wrong adapter. The tool binds the first adapter it finds, often Wi-Fi. Disable Wi-Fi and rediscover; if cameras appear, select the wired adapter inside the tool. The multi-adapter patterns are covered in duplicate PoE camera discovery: diagnose host interfaces.
3. Endpoint protection. Third-party security suites run their own firewall on top of Windows. Add the same UDP 3956 allowance in that console; the Windows rules do not reach it.
4. A broken install wearing a rights costume. Some tools report a generic startup failure as an elevation error. Launch from a command prompt and read the first module that fails — when it is a producer or DLL problem, GenTL producer not listed: check Windows DLL paths shows where the lookup breaks.
5. The OS itself. It is not the cause. The UAC token split behaves the same from Windows 7 through Windows 11, so leave OS updates out of this diagnosis.

Operators without admin rights

Once the rules exist and the NIC has its fixed address, day-to-day camera configuration is plain GVCP over UDP and runs from any account. If your tool insists on elevation at every launch regardless, the clean options are an elevated shortcut — the operator accepts the UAC prompt and types the credential — or keeping configuration on the engineering station and letting the line PCs run acquisition only. The wider question of what standard accounts may install and launch has its own playbook in letting non-admins run specific Windows software.

Before you close the ticket

• Elevated launch done once, and the tool's own firewall exception accepted.
• Firewall rules carry any-profile scope — open wf.msc and read the rule's Profile column.
• NIC and camera pass the mask AND test above; do not trust ping, which can succeed through a router while the discovery broadcast never leaves the local subnet.
• Persistent IP written: power-cycle the camera and confirm it still appears.
• Acquisition software lists the camera when launched from a normal account.
• Connectors screwed tight — the dropout you chased as a rights problem is often a plug half out.

If it still fights you

The recap, one line per case:

• Tool refuses to start, admin or not: elevate once; still failing, it is the install and not the rights, so repair it first.
• Starts, sees nothing: any-profile firewall rule, then the subnet mask test.
• Sees cameras, no images: packet-size pass, then a program rule for the streaming port.

For a new station, the camera finder and the system configurator size the pieces together, area scan cameras and machine vision cables list the parts, and a stubborn error unique to your tool goes to us through the contact page.