External KeyPad Jumps into NumLock Mode since...

It comes down to the basic but extremely sad fact that the protection offered by the Identity Shield cannot operate without making an arbitrary choice about the state of the Num Lock function.  Windows itself does not provide (or specifically programmatically expose) the needed functionality to do otherwise.
 
It is in no way a matter of not wanting to take the issue seriously, nor that there are "not enough complaints".  It's just not physically possible to "fix" because it's technically not our bug.  Trying to fix it is as programmatically impossible as trying to help people with a complaint that Webroot has a file on the computer.  Can't run a program without a file.  Can't detect the desired state of the Num Lock because Windows refuses to tell us.
 
Since Windows doesn't say what the Num Lock state is reliably, we have to make an educated guess.  The default setting on the vast majority of PCs is for the num lock to be on when the computer is started up, so we default to on.  With Laptops, we had a manner by which to detect that it's a laptop and thus trigger it off by default so the function-based number pad wouldn't make it impossible to type things in "iopjklnm,", but even that is not a perfect solution as a tremendous number of laptop keyboards are starting to have segregated number pads these days.  Definitely better than having "poll" come out as "9855" though.
 
In Technical terms:
A program can ask Windows whether the Num Lock is on.  It will tell the truth (or tell us at all) about 75% of the time.  As such, a program that is a keyboard filter needs to make an arbitrary decision about the num lock state.  Since the vast majority use num lock active, that is the decision that was made, except in cases where the computer is very obviously a laptop.  Even something that seems simple like detecting an external keypad is not a simple thing programmatically and given how many people use external numeric keypads to enter numbers, forcing it off based on detecting one would make more people upset than happy.
 
Unfortunately, as I said before, nothing will be perfect.  In all cases, you need to make the decision that is best for you and has the least downsides for your specific situation.  From our perspective, we would invariably fix it if it were physically possible for it to be fixed.  We don't look at things based on how many people are complaining.  We do, however, look at things based on the overall best effect. Sadly, in this case "fixing" it for a handful of folks would leave millions of other people unprotected.
 
The workaround of either turning off the ID shield or setting programs within it from Protect to Allow still exists.  Then at that point it's up to the individual to decide whether the ID shield functionality is a critical part of the software as a whole for their use.  We have thousands of customers who don't care about the ID Shield portion and disable it but still very happily use the rest of the software because going to something else sucks more than having the ID shield disabled.  They just figured that with something else, they'd not have a working ID shield or similar functionality, but they'd also be using a lot more resources, waiting for longer scans, and dealing with companies that don't care about things they -could- fix rather than not being able to fix something that isn't possible to fix.  When they realize that they lose the ID Shield functionality regardless of whether they use Webroot with it disabled or somebody else, but they lose a lot more other stuff as well when they use something else, they generally choose to keep Webroot because its imperfections are less imperfect.  *Shrug*
 
So, vpnavy, sad to see you go.  A lot of people would say that you threw out the baby with the bathwater, but as I said, it's all about making the decision that is best for you.  Since we already know that nothing else works the same way as the ID Shield does, we know you didn't get something else that has a working ID shield feature.  I suspect that you have thrown it out because of a misimpression that we don't care, which I assure you is nothing even vaguely close to the case (I'm QA for Web.  I don't have enough time in a 40-hour work week to do all my normal work, yet I still take the time to give a thorough explanation here).  Even a bit of research on Google confirms in numerous locations that it's impossible to always accurately read the Num Lock state from Windows. If there was any way - by hook, crook, or whacking Windows - that we could change this, we would.  As long as it doesn't reduce protection for everybody.  But this is just a case where Windows itself provides zero solution.

Trojans are generally things that intentionally do bad things.  I'd consider this more of a rare side effect, kind of like medication.  Otherwise Tylenol would be considered a "Trojan Drug" because I happen to have an adverse drug reaction to it and despite the fact that it's supposed to be helpful, if I take it I find out it harms me. 
 
It's one of those tricky situations.  The vast majority of people (and by that I mean literally in excess of 99.9%) default to Num Lock being turned on and never turn it off.  Many don't even know what Num Lock is.  For all of these folks, defaulting to Num Lock being on is a useful and appropriate thing.  We exposed an option for people to select for an entire build before we reverted it. Two weeks with that choice and we got over 70 calls from confused people.  So it was a fix for perhaps six, for example, and a "break" for 70.
 
That being said, we did just revise the manner in which the ID shield works and we have a different options set now as well as some additional functionality in other areas.  We can definitely take a look at options there again.  We can't always say that a given possibility will work and we sometimes have to point things out based on information we have, however we consider the community a very valuable source of ideas as well.  Despite the fact that nearly everybody at the company uses the software at home* for personal use, we can't say that any of us have an external keypad that we want to keep Num Lock off on, for example.
 
We'll see what options we have now with changes to Windows and recent changes to our UI.  As something that would be helpful, could you let us know what specific keypad you have?  If we are able to look at the details of the hardware and drivers, that may potentially give more options as well.
 
(* Only nearly everybody because some of us use Linux.)

oahure, I have good news and better news.

Good News: I have just started a dialogue with our developers and product management regarding your suggestion, and I'll chime in here again when I hear back.

Better News: As it happens, Support has discovered a workaround for switching the default state to OFF instead of ON.  While it's not togglable yet, it's a start.  It involves a registry edit that Support can perform for you.  I'm going to set up a support case for you and handle yours personally.  If anyone else would like this fix applied, please open a support case and include the URL of this topic in the body of your message.
 
(vpnavy, I can work on this for you as well if you'd like?)

Kit:   Did you try simply turning off (disabling) the ID Shield or changing the processes under it from Protect to Allow?
The ID shield can be disabled completely, or the processes under it can be set to Allow instead of Protect, which leaves some ID shield functionality but disables the keyboard filter that would normally be active when those processes are open.  Since the keyboard filter is what locks the Num Lock to a specific state, disabling that should resolve the issue for you completely.
 
I remember going the Protect/Allow - it did nothing.
 
Kit:  Since the issue is with external third party keypads, knowing the keypad allows us to look at ways to detect it specifically and see if its drivers release Num Lock state information, or if we detect a third party keypad, expose options or change functionality based on that detection.  We need to look at things programmatically and look at it based on what a program can see and do.
 
Understood.

I have the Microsoft 4000 keyboard and no external keypad.
 
http://www.microsoft.com/hardware/en-us/p/natural-ergonomic-keyboard-4000/B2M-00012
 
I agree with you, this is not a Trojan.  I just pointed out that it has some similar characteristics in that it is a program I downloaded and paid for to help me and in my situation it did some harm.
 
I am not sure where you got your 99.9% stat, but Wikipedia seems to say the opposite. 
 
They say "Since most modern desktop computers have a full-size keyboard with both a numeric pad and separate arrow keys, Num Lock is rarely used for its original purpose, and ends up confusing the user if it has for some reason been activated without the user being aware of this. This can be more of an issue on most https:///wiki/Laptop_computers, since activating the Num Lock function typically requires use of the https:///wiki/Fn_key and if a user accidentally switches it on they may have no idea how to switch it off. If a full-size keyboard is plugged into a laptop, then the Num Lock function is normally off, and the user would have to activate the Num Lock function to use the numeric keypad for numeric entry."

The Wikipedia article agrees.  Laptops without dedicated numeric keypads default to off, desktops default to on. 
 
When using a full sized desktop keyboard, the numeric keypad is used by most people to type numbers, not to press "up, down, left, right, home, end, page up, page down", etc.  There are already keys for all the arrows and home/end and such, so why have the numeric keypad do the same thing as those dedicated keys?  So Num Lock is on by default and pressing the "9" key on the numeric keypad types a nine instead of going up a page.
 
That is why we set it to On on desktops and Off if we detect a laptop.  There is also supportive evidence in the point that out of millions of users and thousands of people reading these forums, only two have expressed a problem with it. :)
 
Work with the support ticket to change the default, or disable ID shield, or set to Allow instead of Protect.  Many solutions, so you get to choose which one works best for you.

I think we can all agree that some people prefer it on, and some people prefer it off.  And other people prefer turning it on and off.  There are probably a lot of people in all of those groups, no matter what the percentages are.  Oahure has a good feature request (or defect observation, depending on how you look at it), and we've brought this up with product management for review.
 
In the short term, we've got a workaround available through Support now, within 24 hours of this thread being dredged up from it's 8-month-long slumber (and 24 hours turnaround time with a fix is pretty good I'd say).
 
So, in the holiday spirit and to celebrate having some success with this issue, I would like to offer everyone this picture of eggnog:
 

 
:cattongue:
 
I'll follow up again when we hear back from product management (or product management may even chime in here as well).  Please be mindful the holidays are nearly upon us, so the workaround may need to suffice for a bit.

(Oahure, your support case is awaiting a reply, and Vpnavy, please let me know if you change your mind, and I'll be happy to help.)

>Since Windows doesn't say what the Num Lock state is reliably, we have to make an educated guess. 
 
You don't have to make an educated guess. Put a "num lock" checkbox in your software.
 
Jay

Hi Kit,
 
You mentioned you revised the manner in which Identity Shield works.
 
Does this mean I can enable it again without the Num Lock issue?

OK, I will wait for support to let me know how to do the registry entry so I can enable ID Shield again, thanks.

@ wrote:
 >We'll see what options we have now with changes to Windows and recent changes to our UI.
 
Thanks!  Let me know how to set the numlock one way or the other. I don't switch it back and forth. I can patch the registry if necessary.
 
Jay

Just open a support ticket and the direct support team will be able to provide that information.

That worked great, thanks.  It is nice to be fully protected again.