UAC violations
Having managed a few networks in my time, I've dealt with windows boxes and related security issues on various levels, and nothing was more telling than when dealing with locked-down user accounts.
Most readers on this site will be accustomed to small-to-medium windows networks where most users are granted a modicum of trust and rights over their own personal systems, but when you have environments like schools, prisons, call centres it is policy to "lock it down 'til it squeaks" that you start to see some of the dirty habbits of software you previously considered respectable.
Once you've locked down a winXP system, it is nigh impossible to infect it. Buffer overflow code executions fail when they attempt restricted actions. Process user elevations never happened because policies specify a whitelist of trusted locations locally and externally that executables can be run from.
We never had a problem with the students desktops (the teachers laptops on the other hand...)
Secure, that is, until you start having to punch dirty great holes in your own security to get shoddily designed bits of software working.
Firefox is a classic example. It's self update system breaks several fundamental rules of the windows environment. The most obvious of which, attempting to write back to its' own program folder.
This should never happen. The updating component should have been installed as a local service.
What really irks me, is that these aren't brand new rules that you could forgive people struggling to catch up with. The NT family were deisgned from the get-go so that in everyday use you run as a limited user but there are still too many lazy coders out there who take shortcuts that compromise the whole systems security, forcing you to run as root.
The UAC isn't intended as a direct security measure. It's there to embarrass the coders into writing their software in compliance with the platform they are developing it for. Just think of it as a big FAIL sticker on the 3rd party software everytime you see it.