Keypad messages handling on HTC

I'm facing problems with keypad handling, which I observed on HTC devices (I do not have similar problems with HP iPAQ). The result was either the significant program slow down or in the worse the FPS falls to 0 (so the scene was not updated), depending on how fast I was pressing buttons. I have found that problem happens when user presses buttons quickly in sequence. Then the message processing loop becomes too busy and is never leaved, so the screen redrawing is stopped. Below is the simplified game loop. It consists of two parts, at first messages from the queue are picked and handled and then the scene is rendered. Because the PeekMessage() while loop is too busy with key messages handling, it is not leaved and consequently the Update() function is never called.

while ( isRunning )
{  
  ...
  // 1a. Pick up message
  while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
  {
    //1b. Handle message
  }

  // 2. Renders scene
  Update();
  ...
}

I do not understand, what is wrong with HTC devices, that they handle key press related message so slowly, that it blocks the game loop. I thought this is a common issue, so I tried to search Internet, but the only reference I found was there http://blogs.msdn.com/windowsmobile/archive/2007/08/13/have-you-migrated-to-directdraw-yet.aspx. Guy named Fred Di Sano wrote:
"…Getting input via the message pump is kind of clunky and in some cases (like on various HTC devices) it slows down the app!", but I do not find any other reference..."

I did not found any solution except defining the maximal number of messages that can be processed in the loop iteration:

// Max. messages that are processed in one step
const int KMaxMessagesProcessedInOneStep = 3;

while ( isRunning )
{
 ...
 // Messages processed
 int messagesProcessed = 0;
 // 1a. Pick up message
 while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) 
 {
   //1b. Handle message

   // Check how many messages were processed
   messagesProcessed++;
   if ( messagesProcessed > KMaxMessagesProcessedInOneStep )
     break;
 }

 // 2. Renders scene
 Update();
 ...
}

I believe this is not the best solution, so if anyone can suggest something better I will appreciate it.