Well normally the upgrade from WinPcap 2.2 to 2.3 to 3.0 was fine, I did nothing special, but according to
http://winpcap.polito.it/misc/changelog.htm under "Version 3.1 beta, 3 feb 04"
Changes/additions to the Packet.dll API:
# PacketGetAdapterNames() now returns the names of the adapter in ASCII rather than in Unicode. Since the main purpose of PacketGetAdapterNames() is feeding data to pcap_findalldevs() and since pcap_findalldevs() needs ASCII names, the new PacketGetAdapterNames() avoids a conversion in wpcap.dll and uniforms the data format with the one of Windows 9x (this potentially simplifies the code of the applications). As a consequence of this modification, old applications won't work properly with the new PacketGetAdapteNames() on NT/2k/XP/2k3.
# PacketOpenAdapter() now takes an ascii adapter rather than a UNICODE one. This is a consequence of the fact that PacketGetAdapterNames() returns ASCII strings: they can be immediately passed to PacketOpenAdapter(). (note: internal conversion is provided so that a UNICODE adapter name will be correctly opened, however the prototype changes and this could generate warning when compiling old applications).
They might have changed code in packet.dll which breaks GIT there - I could probably fix GIT if its really a problem, wouldn't be too much work.
They warn at
http://winpcap.polito.it/docs/docs31bet ... etapi.html that using packet.dll is not the recommended way of using winpcap, but if I remember correctly, some of the functionality GIT needs is only available using direct to packet.dll instead of wpcap.dll
I forget what exact functionality or reason I had for chosing to go with packet.dll instead of the slightly higher-level capture driver, but its too late now to change things.
This could break GIT again in the future with newer winpcap versions, but hopefully the changes are easy enough to implement.