Edit: 3 minutes later, first zombie just appeared. Sorry.
Run it in full debug mode storing the log somewhere until the zombies appear to see what it might be that provokes them.
i.e. start it with the extra commands: -D 2>log.txt
and send me the log.txt file.
Note that if, despite all the absurd extra code I put in, you are still having problems, it may not be code at all, so check connections, power cables, adequate power, OS etc.
Latest binaries are ok for last 4 hours for me. Still logging just in case.
By the way is that only me using --text-only to get proper debug.log?
That -D 2 > log.txt does not work in windows for me. Is there a way to log and keep console updating in windows?
PS. That was great to know about quotas

Note that "-D 2>log.txt" works in windows as well, and does not need to be in text only mode. Note also there is no space after the 2. However the windows log file might not flush until cgminer shuts down due to the way windows writes to files so it may look zero sized indefinitely.
It's getting interesting.
I took one machine back to 3.1.1 and it has had no zombies for three hours. It probably would have had at least one by now when running 3.5 or 3.6.
I rebooted and started logging on the other machine, still using 3.6.4. with your new exe temporary fixes. It has had no zombies since. It almost certainly would have had a couple by now without the log running!
Speculation: Of course a zombie might show up at any moment but for now this feels like it might be a timing issue. Might the old (relatively inefficient?) 3.1.1 and the overhead of logging each slow some component enough to keep it from timing out?
I'll post if the log catches a zombie, but no news is good news for now.
Issue that is probably unrelated, but perhaps worth mentioning - Slush's pool has been having issues today. Whenever I've been getting zombies I've been connected to that pool but these new zombie-free runs happen to be using BTCGuild. Probably coincidence, but one more variable, I'm afraid.