http://bugs.winehq.org/show_bug.cgi?id=18786
--- Comment #19 from Juan Lang juan_lang@yahoo.com 2009-06-26 11:44:46 --- Hi Guy, I've taken a look at the two logs, and the code.
I agree that the logs are different, but I think the code is more correct as it is than it was before. For example, in the current git with your trace patch applied, the first call to SnmpExtensionQuery is:
0009:Call inetmib1.SnmpExtensionQuery(000000a1,0032f89c,0032f874,0032f878) ret=65024e7f trace:inetmib1:SnmpExtensionQuery (0xa1, 0x32f89c, 0x32f874, 0x32f878) trace:snmpapi:SnmpUtilOidNCmp (0x32f674, 0x32f590, 6) trace:snmpapi:SnmpUtilOidToA (0x32f674) trace:snmpapi:SnmpUtilIdsToA (0x15a3d0, 11) trace:inetmib1:SnmpExtensionQuery 1.3.6.1.2.1.2.2.1.3.1
This is a call to get the interface type of the first interface in the system. 1.3.6.1.2.1.2.2.1.3 is the MIB2 OID for ifType, and 1 refers to the first instance.
You then point out: trace:inetmib1:mib2IfEntryQuery (0xa1, 1.3.6.1.2.1.2.2.1.6.1, 0x32f598) trace:snmpapi:SnmpUtilOidNCmp (0x32f68c, 0x32f4e8, 9) trace:snmpapi:SnmpUtilOidNCmp (0x32f68c, 0x32f4e8, 9) err:inetmib1:getItemAndIntegerInstanceFromOid git code *item=6
*** first difference
trace:snmpapi:SnmpUtilAsnAnyCpy (0x32f694, 0x32f474)
In fact, the instance *should* be 6, and the item should be 1. So I don't see what the problem is. In this case, the application is querying for the MAC address of the first interface in the system. 1.3.6.1.2.1.2.2.1.6 is the MIB2 definition of ifPhysAddress, and 1 refers to the first instance.
Later you point out: *** note repeated call to SnmpExtensionQuery
0009:Call inetmib1.SnmpExtensionQuery(000000a1,0032f89c,0032f874,0032f878) ret=65024e7f trace:inetmib1:SnmpExtensionQuery (0xa1, 0x32f89c, 0x32f874, 0x32f878) trace:snmpapi:SnmpUtilOidNCmp (0x32f674, 0x32f590, 6) trace:snmpapi:SnmpUtilOidToA (0x32f674) trace:snmpapi:SnmpUtilIdsToA (0x15a3d0, 11) trace:inetmib1:SnmpExtensionQuery 1.3.6.1.2.1.2.2.1.3.2
This is a call to retrieve a different OID, 1.3.6.1.2.1.2.2.1.3.2. This is the ifType of the second interface in the system. Again, 1.3.6.1.2.1.2.2.1.3 is the ifType, and now 2 refers to the second instance. Immediately after this, unsurprisingly, the app queries the MAC address of the second interface, with: trace:inetmib1:SnmpExtensionQuery 1.3.6.1.2.1.2.2.1.6.2
So this looks correct to me.
You also point out: 009:Call KERNEL32.GetLastError() ret=6504065b
*** !!!!! note error ERROR_NO_MORE_ITEMS
0009:Ret KERNEL32.GetLastError() retval=00000103 ret=6504065b
Sure, okay, but that isn't set by inetmib1. You should see where that's coming from, as that's a more likely source of the problem that inetmib1. That is, inetmib1 appears to have been buggy before, and now it shows a bug elsewhere.