I doubt WM_INPUT is to blame for this. At the very most, you're doing something pathological in your window procedure when handling WM_INPUT, which leads to these symptoms; but without seeing your code, it's anyone's guess as to what exactly you may be doing that needs to change.

That sounds suspiciously like an improper message loop. Show your message loop and window proc.

Using WM_INPUT is not easy, and I am also wondering if it makes more sense to just capture WM_LBUTTONDOWN and WM_CHAR messages since my game is a 2D platformer and doesn't need super fast input handling for the game play.

I disagree. I think raw input is just what I need. Problem is understanding what it isn't. My problems are amplified by the fact I am not a standard keyboard user.

WM_INPUT is not a good way to emulate WM_CHAR. CHAR messages contain considerable more information, are generated way differently and go through consistent mangling. Do not map WM_INPUT to WM_CHAR. It is possible, but just not necessary, just get WM_CHAR. What is WM_CHAR for?
WM_CHAR says "append character 'x' to text buffer". Or perhaps, if caps lock is on "append character 'X' to text buffer". Both chars are generated by the same button.
For your information (I assume you're writing from QWERTY-US), my keyboard would generate 'q' and 'Q' respectively.
This is what WM_CHAR does, it looks at the buttons being pressed and maps to the appropriate character. It also takes appropriate consideration of control panel settings regarding keyboard repetition speed and stuff like that.

WM_INPUT does nothing like that. The misconception arises as most people never have to deal with anything else than QWERTY-US. WM_INPUT always identify buttons, not characters, based on (apparently) a standard QWERTY-US layout.
So, button C will generate 'c' in QWERTY-US and 'j' in my keyboard layout, but it's always in the same physical position. This is very important, it implies your keyboard mappings will never, ever change because of locale. Your WASD cross will always be a cross, even if the buttons are marked differently.

Do not bind actions by characters. For first, what's the deal with 'c' against 'C'? What happens if the user has a different keyboard layout?

For all text-related purposes, I think WM_CHAR is just the best option.
Personally I use WM_INPUT for hi-prec mouse movement only.

You wanna be using VK codes any way with message loop inputs, as they should map language and hardware independantly to the correct characters.

Example:
Taking Advantage of High-Definition Mouse Movement.

I think it's worth making clear that I do not endorse WM_INPUT for keyboard mangling. I agree with NightCreature and his suggestion to use virtual key codes (that's also what I am doing).