In addition to what Bacterius and L. Spiro already said, the time taken by TranslateMessage+DispatchMessage is not deterministic -- wait, that's a wrong wording. It is deterministic, but it is neither obvious, nor constant. Not only your window proc, but also the default window proc may take vastly different amounts of time to process messages, and new messages may be generated (as a consequence of messages being received) that you even don't yet know about. In an extreme case, these two harmless lines of code could take 20 times longer than they usually do.
Most likely this will not be the cause of your problem, but still it is unwise to wrap a high resolution timer around such a thing (and around Sleep on top of that) and expect something meaningful to happen.
About Sleep, this is a valid objection. There is nothing less likely to break your timings (or your frame rate, for that matter) than calling Sleep. On the other hand, it is also a valid cause not to let the CPU busy wait all the time because of power consumption. However, this is not the case where it matters most anyway, and where it matters less you might even want that exact thing to happen.
One usually wants to save power on mobile devices where busy waiting will drain your batteries much faster (assuming you're not plugged in). However, on those devices, vertical sync is usually forced on by the drivers, so there is some built-in rate limit anyway. The game renders, so inevitably, it will be throttled. Of course, in between it will still run busy. But, even on a mobile device this may be a benefit.
On desktop computers, being busy is more often a benefit rather than a disadvantage, even if it burns a little more power. Unluckily, operating systems apply the power saving craze just as often when it doesn't make sense as when it makes sense. If you search the web for "game stuttering", you'll come up with "fix" instructions like these (which will more likely than not cause unwary users to break something!) for that exact reason.
When a CPU is not utilized, the OS will usually reduce its frequency or even "park" a core alltogether, even if you're on a desktop computer with a thick plug in the wall. This is OK when you're half-asleep in front of Microsoft Word at your boring office job. It is, however, not a big win while a game is running. Not at all. Effectively, the CPU runs at one half or one third of its speed when the only thing you really need is... speed.
This power saving craze is so extreme that for example on my ASUS notebook, I cannot even get the CPU to run at maximum clock speed. I paid for a CPU that can do 2GHz, but it will never run any higher than 1.7GHz, even if I start a program that has 2 threads busy running. On "idle" (i.e. if no program is busy spinning and you don't press a key for about 2 seconds), it runs with 0,58GHz using a single core. The result is that when you start your web browser or mail program, it takes literally seconds before it's ready (happens "instantly" on desktop). Because hey, we must save power. They don't account for the fact that if everything takes longer, this consumes power too, and your life time.
Power throttling is exactly the kind of thing that you normally don't want to happen in a game. Insofar, while the argument against busy waiting is valid, it is not valid without restrictions. In any case, however, there exist better options (Bacterius mentioned waitable timers, to name an example) than Sleep to prevent busy waiting.
Unluckily I can't remember the URL now, but there was a funny (well, funny if it doesn't happen to you) site a while ago about a guy who spent big $$$ to buy a faster server, only to discover that the stupefied power throttling made his new server run at less than 50% of its speed because he was only using two out of four cores (those 100% loaded, though), effectively being slower than the old one.