A use case for Microsoft debugging tools in memoQ support
Reference Number: AA-00718 Created: 19-11-2014 00:44 Last Updated: 19-11-2014 01:09 0 Rating/ Voters

Description:    There are some types of software issues that are not obvious and there is no information readily available to investigate the causes. We often hear from people in software development these problems require "debugging", which traditionally means that a developer who has the source code and the development environment must be able to reproduce the problem in question, and use the development environment to find the cause and resolve it. Because debugging must happen on the developer's end, and reproduction is not always obvious, some cases lead to a dead-end, and are never resolved.

This here is a case where I encountered an issue that looked like one of those: while checking out a project, memoQ produced 25% CPU load, which basically meant that it was fully utilizing one of the the logical CPU cores in the system, and that CPU load remained after the checkout finished. (The PC had a dual core Intel CPU, which looks like four cores to Windows.) Even on the customer's system, the problem didn't always occur: if the user checked out to the G:\ drive (where they wanted to), it occured. When checking out to the D:\ drive, it didn't occur. It of course didn't occur when trying on my system. So I decided I'll try to "debug" right there on the customer's PC. I had Google to help me.

How to:    The problem was that after the checkout, memoQ was sitting idle, not doing anything useful, but still using 25% CPU. Here's how I found the cause and fixed it.

  1. Do very naive searches on the web like "find out what a process is doing". No kidding, exactly this search (with the quotes) helped me get started. The first Google hit was this:
    http://blogs.msdn.com/b/pfedev/archive/2007/12/01/investigate-high-cpu-for-a-process-part-1.aspx
    I used it to guide me.
  2. Install Process Explorer
  3. Find the memoQ process in the list, right-click and click Properties. Then click the Threads tab. Process explorer will tell you that it requires additional software: Microsoft debugging tools. Click the link.
  4. On the web page that opens, click "Get the standalone debugging tools (WinDbg) as part of Windows 8.1 SDK". Download it and run it. Install nothing but the debugging tools from everything that is offered
  5. Now you can see all the threads of memoQ.exe in Process monitor, and which thread is using all the CPU capacity it can. You will also see a "start address" next to each thread. In my case the CPU hungry process had something like rtlvalidateheap as "start address". You'll probably have no idea what that means, I certainly didn't.
  6. Do a naive web search for the Google keywords rtlvalidateheap and cpu. In my case, the third hit contained the answer: a bug in Windows 7, for which there is a hotfix:
    http://forum.sysinternals.com/profsvc-high-cpu-usage_topic29213.html
Rss Comments (Please do not post support requests here.)
  • There are no comments for this article.
Info Add Comment
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu
Info Missing an article? Let us know!