2.12% of CPU usage mean that there is no synchronization conflict and execution flow is not within an infinite loop. Such percents tell that the process takes and releases CPU quantums in normal mode. Next step to try is to attach the debugger running PrjServer.exe process:
-
Find the PID of PrjServer.exe in the Process Explorer
-
Find the TID of the thread that eats the CPU time
-
Run
cladb -p <pid> -
In the debugger open the Thread List window (main menu → Window → Thread List)
-
Highlight the line for the thread with found TID
-
Press the Ctrl-Space key to suspend selected thread and the press the Space key to show that thread’s in the Stack Trace window
-
Right click on the most bottom upper-level node in the Stack Trace window and choose the Locate In Assembler item in the popup menu
-
Make the height of the disassembler window as much as possible and provide the screenshot.
If execution flow is withing .Net managed code or thread structures are damaged (0-address as the thread start address can tell about this) failing is possible on one of steps.
All the Win32 part of CW is building using internal command-line utility which does not use .Net, and there are no any problems with making projects in any mode.
Multiple reasons are possible why results of making are different in release and debug modes can be. For example, MSBuild can fail on parsing some debug-related parameters in the CWPROJ project.