When you have checksums offloaded to your network card, then a sniffer on the host sniffs the packets -before- they go to the network card, and so sniffs the unadjusted checksums. The network card then fixes the checksums and sends out the corrected packet.
I'm not sure from your posting whether you did not know that, or if you have reason to believe there are checksum errors -after- the NIC rewrites the checksum (e.g., somewhere in transit between the NIC and the receiving end) ?
When checksums are offloaded to the driver, then for any particular protocol, the checksum field stored in the packet (the one that is sniffed) will be either a constant or whatever trash happens to be handy. Either way, by chance sometimes that is going to be the correct checksum: in order for the value to *never* be right, the drivers would have to calculate the checksum and then deliberately put in something it knew to be wrong.
Another thing you might observe is that different protocols involve different numbers of checksums. With checksum downloading turned on, there may be a pattern of incorrect checksums -- e.g., it might happen for all TCP packets but not for other packets.
It sounds like the easiest solution is to leave checksum downloading disabled ;-)
If the NIC is not processing checksum regeneration properly, then it could be having other difficulties that might lead to the bad packets never leaving the NIC. You need try snooping the data -after- it leaves the NIC, such as by using SPAN or RSPAN to "mirror" the switchport data over to another port for analysis.