Forum Discussion

Utnapischtim's avatar
Utnapischtim
Copper Contributor
Aug 10, 2026

SNMP Query fails with Error: Error in packet. Reason: (genError) A general failure occured

I have enabled a win Server 2022 and a Win11 machine to answer SNMP requests.

However both machines run into error while doing a snmpwalk.

I have started with OID just before errornous OID.

Both machines show same behaviour.

Does someone experience same problem?

Can someone recreate this problem?

Does someone know a cure fort this problem?

Does someone have any ideas how to proceed?

 

root# snmpwalk -Os -v 1 -c public <hostname> .1.3.6.1.4.1.77

comVersionMaj.0 = STRING: "10"

comVersionMin.0 = STRING: "0"

comType.0 = Hex-STRING: 03 00 00 00

Error in packet.

Reason: (genError) A general failure occured

Failed object: comType.0

 

root@monitor:/etc/munin/plugins# snmpwalk -On -v 1 -c public <hostname> .1.3.6.1.4.1.77

.1.3.6.1.4.1.77.1.1.1.0 = STRING: "10"

.1.3.6.1.4.1.77.1.1.2.0 = STRING: "0"

.1.3.6.1.4.1.77.1.1.3.0 = Hex-STRING: 03 00 00 00

Error in packet.

Reason: (genError) A general failure occured

Failed object: .1.3.6.1.4.1.77.1.1.3.0

 

 

 

accessibility

1 Reply

  • Surya_Narayana's avatar
    Surya_Narayana
    MCT
    Aug 31, 2026

    hi Utnapischtim​  The fact that the same failure occurs on both Windows Server 2022 and Windows 11 is interesting. It makes a problem with the individual machines less likely and points more toward the Windows SNMP implementation or the particular OID being queried.

    The important clue is that the walk succeeds for:

    .1.3.6.1.4.1.77.1.1.1.0

    .1.3.6.1.4.1.77.1.1.2.0

    .1.3.6.1.4.1.77.1.1.3.0

    and then returns genError specifically on comType.0.

    A few things would be worth checking:

    Query that OID directly rather than using snmpwalk to confirm the behavior.

    Try SNMP v2c as well as v1 and compare the result.

    Check whether the same OID fails when queried using another SNMP client/tool.

    Capture the SNMP traffic with Wire shark. The response packet should show whether Windows is returning genErr and, importantly, what error-status/index is being returned.

    Check the SNMP service configuration and Windows event logs for anything related to the SNMP service.

    It may also be worth testing a few OIDs before and after .1.3.6.1.4.1.77.1.1.3.0 rather than assuming the failure means the entire MIB walk is broken.

    Since the failure is reproducible on two different Windows versions, the packet capture would probably be the most useful next step. It should help determine whether the problem is with the Windows SNMP agent returning genErr for that particular MIB object, or whether something is happening in the SNMP client during the walk.

    If someone can reproduce it on a fully patched Windows 11/Server 2022 system, comparing the actual SNMP response packet would also be very useful.