Well I was one of those infamous unlucky guys who had the "kernel debugger" problem too (right after fresh windows).
The source in MY case was: SPTD 1.50 installed prior DTool 4.091.
Dtools installed it's 1.43 SPTD (or updated or whatever it did).
So, those two hated each other.
Checking was:
Check device manager (you have to use the show-hidden-devices options from the menu).
SPTD was either ! or X.
You can delete it there, but that does not really help, and you may have to to it TWICE or more if you have a huge number of SPTD versions accumulated, each time rebooting after removing.
That way I noticed that there must be two SPTD's installed.
The real fix was:
For every SPTD version I had installed, I ran (in my cases):
SPTDinst-v143-x86.exe remove
reboot
SPTDinst-v150-x86.exe remove
reboot
and then normal:
SPTDinst-v150-x86.exe
to install (+reboot)
I did not need to uninstall or remove dtools itself, the already installed dtools accepted the 1.50 SPTD driver without any strange sideeffects after the cleanup, it works just like nothing was ever wrong.
Have fun!
AH
The source in MY case was: SPTD 1.50 installed prior DTool 4.091.
Dtools installed it's 1.43 SPTD (or updated or whatever it did).
So, those two hated each other.
Checking was:
Check device manager (you have to use the show-hidden-devices options from the menu).
SPTD was either ! or X.
You can delete it there, but that does not really help, and you may have to to it TWICE or more if you have a huge number of SPTD versions accumulated, each time rebooting after removing.
That way I noticed that there must be two SPTD's installed.
The real fix was:
For every SPTD version I had installed, I ran (in my cases):
SPTDinst-v143-x86.exe remove
reboot
SPTDinst-v150-x86.exe remove
reboot
and then normal:
SPTDinst-v150-x86.exe
to install (+reboot)
I did not need to uninstall or remove dtools itself, the already installed dtools accepted the 1.50 SPTD driver without any strange sideeffects after the cleanup, it works just like nothing was ever wrong.
Have fun!
AH