Hi Sam,
An interesting issue. Personally, I would start by looking carefully at the show ip dhcp binding output and having a look whether the recorded leases have the proper lease time indicated. If not then it would be worth trying to sniff the DHCPACK messages to see what timeouts they contain and in what relationship they are in comparison with the DHCP snooping database.
An entry in the DHCP snooping database will be removed if the associated port goes down. Also, while I am not completely sure about it I suspect that other connectivity changes could also account for flushing an entry - 802.1X authentication failure, STP role/state change on a port or similar. That would be my second guess - to check whether there are events similar to these that could potentially cause the DHCP snooping entries to be flushed. Note that Windows in particular tend to ignore short connectivity issues and they often do not renew their DHCP lease after an intermittent connectivity problem.
If debugging is possible for you, I would also have a look for the output of the debug ip dhcp snooping event command (and the related debugs) to see if any reason for flushing an entry from the snooping database is indicated.
Best regards,
Peter
