Yes, absolutely, the drivers are fine..
It is just that, for some odd reason, the bug that I've been experiencing (or, odd behavior) was very intermittent, sometimes showing after 5 minutes and at other occasions after 5 or 10 hours, but when using the drivers it showed up quite quickly, which again led me to falsely suspect the drivers for being the culprit to the oddity..
I did find the bug eventually, it appears that I must have been tired at the point of writing and examining the code, as the bug turned out to occur when a dns resolution request for a host/domain with no . in it was issued, just like Chrome does when it's launched (three times to be exact) - probably to determine which dns servers are used or if it's even online - or something..
In Firefox this would lead to the injected .dll getting trapped in an eternal loop, the browser's dns resolution request probably eventually times out and it it self continues, but the .dll running within the context of the browser continues using cpu resources in the loop, as the same code is called multiple times, more and more instances of the loop is running (in separate threads) and the cpu usage of the application appears to steadily increase.
It was actually by testing in Chrome that got me on the path to figure it out, since Chrome would not work at all (I was probably blocking it's dns resolution threads) while Firefox and IE would (apparently) work and Firefox would over time (use) eventually start to wind up.
Why the shell (explorer.exe) is attempting to resolve no-tld names I don't know, but then again, the explorer shell does a lot of things that are not obvious..
So eventually I caught it, when I added critical sections to the .dll to examine where it would loop and saw where it stopped and never exited..
Thanks madshi, you're the man