What can cause this error?

Idk if there is a limit but it could be to many injections at a single time. (Idk, just throwing the idea out there.)

Similar issue:
Wow stays unfrozen, but wRobot (interface too) is frozen.
When I force-kill wRobot.exe process, WoW throws this error:

ERROR #132 (0x85100084) Fatal Exception
Program:	F:\Games\WoW 3.3.5\Wow.exe
Exception:	0x80000004 (SINGLE_STEP) at 0023:66D54590

I think it happens when wRobot targets itself (or others) using Interact.InteractGameObject

I think it has do to with me suspending CustomClass.Thread, like this:

private void FightClassWaitForRegen()
{
  List<Thread> threadsToSleep = new List<Thread>();
  threadsToSleep.Add(CustomClass.CustomClassThread);

  var fightClassSleepThread = SleepFightClassThread(threadsToSleep);
  WaitUntilRegenerated(threadsToSleep);
  fightClassSleepThread.Abort();
}

private Thread SleepFightClassThread(List<Thread> threadsToSleep)
		{
			Thread fightClassSleepThread = new Thread(() =>
			{
				try
				{
					foreach (var thread in threadsToSleep)
					{
						thread.Suspend();
					}

					while (Conditions.InGameAndConnectedAndAliveAndProductStarted && !Common.IsAttackedByNpc)
					{
						Thread.Sleep(500);
					}
				}
				finally
				{
					foreach (var thread in threadsToSleep)
					{
						thread.Resume();
					}
				}
			});
			fightClassSleepThread.Start();
			return fightClassSleepThread;
		}

I don't really know the code, but FightClassWaitForRegen is run by a wow thread, afaik it is actually run by directx by a hardware break and you sleep this thread -> while (Conditions.InGameAndConnectedAndAliveAndProductStarted && !Common.IsAttackedByNpc), so assuming that the first condition is true, it will sleep the thread updating your code until Common.IsAttackedByNpc becomes true, thisway stopping the originally directx thread from doing it's original job. Guessing from the variable's name it isn't constantly true, rather occasionally. I wouldn't sleep the thread based on that.

Edit: the single step exception is actually caused by killing wrobot (the handler for the SEH exception from the hardware bp gets lost)
Edit2: Even if that code is run outside of the client, the cause of the problem might be similar.

Yeah, I figured if I'm suspending the CustomClassThread while it's writing to client memory (not allowing it finish whatever work it was doing) it would either deadlock wRobot or the wow client itself (through directx endscene), while I was testing some things.

I decided it's time I write my own customclass implementation that allows me to properly pause it from an outside thread and provides more customizability than what wRobot currently offers. 

Thanks for the insight though, that was very helpful.