A Windows App Developer's Primer on CPU Settings: Priority, Affinity, and P-cores/E-cores

The performance of a Windows app is not determined by code alone. The same .exe can feel different depending on the PC it runs on.

On one PC, the periodic processing is stable.
On another, it occasionally lags.
On AC power there’s no problem, but on battery it’s oddly slow.
You raised the priority in Task Manager, but it didn’t get as fast as you expected.
You thought you had steered it onto the P-cores, but the processing time still jitters.
Conversely, when you tried to raise performance, the fan never stopped and other apps became sluggish.

When you build Windows apps, you run into these “phenomena that are hard to explain from the code alone.”

When that happens, these are the four things to look at.

Furthermore, on modern Windows, EcoQoS and Task Manager’s Efficiency mode are also part of the picture.

In other words, a Windows app’s execution environment is not simply “is the CPU fast or slow.”

When it gets executed
Where it gets executed
What kind of core it gets executed on
What performance state the CPU is running in
Whether the OS considers it "performance-critical" or "fine to run power-efficiently"

These factors combine to determine the actual responsiveness and processing time.

This article organizes the relationships among priority, affinity, P-cores/E-cores, and power-saving settings — things that are easy to overlook in Windows app development.

The code in this article is published on GitHub as a buildable, runnable sample set (a C# library and demo handling priority and affinity, PowerShell scripts, and unit tests).

windows-app-cpu-priority-affinity-power - komurasoft-blog-samples (GitHub)

1. The Big Picture First

To start, here is the big picture as a diagram.

flowchart LR
  A["Application code"] --> B["Windows scheduler"]

  P["Priority<br/>how readily it gets executed"] --> B
  AF["Affinity / CPU Sets<br/>which CPUs it may run on"] --> B
  Q["QoS / EcoQoS<br/>performance-focused or power-efficient"] --> B

  B --> C["Choose the thread to run"]
  C --> D["Choose the logical processor to run on"]

  PE["P-cores / E-cores<br/>performance-leaning or efficiency-leaning"] --> D
  PM["Power mode / power plan / PPM<br/>frequency, boost, Core Parking"] --> D

  D --> R["Actual responsiveness<br/>processing time<br/>heat<br/>battery drain<br/>impact on other apps"]

The important thing is that these are not independent.

Raise the priority, and the thread becomes more likely to run.
But if the CPU itself is being managed toward power saving, it may not get as fast as you hoped.

Narrow the CPUs with affinity, and thread migration may decrease.
But if the narrowed set lands on efficiency-leaning cores, or clashes with Core Parking and power management, it can backfire.

Steer onto the P-cores, and the computation may get faster.
But push everything onto the high-performance side and you increase heat, fan noise, battery drain, and the impact on other processes.

Tuning Windows app performance is not a simple hunt for a “make it faster” button.

Which processing do you want to be fast?
Which processing is allowed to be slow?
Do you prioritize responsiveness to user input?
Do you prioritize completion time of background work?
How much battery drain and heat will you tolerate?

It becomes a question of that design.

2. Priority Is “How Readily It Gets Executed”

On Windows, when multiple runnable threads exist, the scheduler decides “which thread goes onto the CPU next.” This is where priority comes into play.

Broadly, priority is determined in two stages.

Process priority class
  + thread relative priority
  = thread base priority

In Win32 API terms, there is SetPriorityClass on the process side and SetThreadPriority on the thread side.

To view the priority of a running process in PowerShell, for example:

Get-Process -Id $PID | Select-Object Id, ProcessName, PriorityClass

To raise the priority of the current PowerShell process:

$p = Get-Process -Id $PID
$p.PriorityClass = "AboveNormal"

In C#, you can write it like this:

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.PriorityClass = ProcessPriorityClass.AboveNormal;

The thing to note here is that priority is not a “make the CPU faster” setting. What priority affects is which thread runs first when there is contention.

It is not a setting that raises the CPU frequency.
It is not a setting that selects P-cores.
It is not a setting that speeds up I/O.
It is not a setting that eliminates lock waits or network waits.

That is why “I raised the priority but it didn’t get faster” is entirely common. If the slowness is caused by things like the following, raising the priority will not fundamentally solve it:

• Waiting on disk I/O
• Waiting on the network
• Waiting on a DB response
• Lock contention
• GC pauses
• A blocked UI thread
• Waits on the GPU or driver side
• File scanning by antivirus software
• The CPU frequency being held down toward power saving

Also, HIGH_PRIORITY_CLASS and REALTIME_PRIORITY_CLASS are not things to use casually.

A thread that keeps running at high priority for a long time becomes reluctant to yield CPU time to other threads.
If that stayed inside your own app, fine — but it can degrade the responsiveness of the entire system.

Priority is like medicine.

In the situations where it works, it works.
But more is not better.

Things to consider before raising priority

Before raising priority, there are things worth considering first.

What matters in a Windows app is not always running at top priority, but prioritizing the necessary processing at the necessary time, over the necessary scope only.

3. Affinity Is “Which CPUs It May Run On”

If priority is “how readily it gets executed,” affinity is “which CPUs it may run on.”

On Windows, you can specify the set of logical processors a process or thread is allowed to run on.

In the Win32 API, there is SetProcessAffinityMask for processes and SetThreadAffinityMask for threads.

To view a process’s affinity in PowerShell, for example:

Get-Process -Id $PID | Select-Object Id, ProcessName, ProcessorAffinity

For verification purposes, to restrict the current PowerShell process to the first 4 logical processors, you can write:

$p = Get-Process -Id $PID
$p.ProcessorAffinity = [IntPtr]0xF

0xF is 1111 in binary.
That is, it means logical processors 0-3 are allowed.

But this is strictly a verification example.

Narrowing affinity can improve CPU cache locality and reduce jitter in periodic processing.
On the other hand, it also pens threads into a narrow space when Windows could otherwise have shifted them to idle CPUs.

You need to be especially careful in environments like these:

• P-cores and E-cores coexist
• With SMT/Hyper-Threading, the mapping between logical processors and physical cores is not intuitive
• It is a NUMA configuration
• Processor Groups come into play beyond 64 logical processors
• Core Parking is enabled
• OEM or BIOS power management is aggressive
• It runs in a virtualized environment

Affinity is a setting that imposes a fairly strong constraint on the system: “run only on these CPUs.”

Constraints can be a tool for stabilization.
But get them wrong and you cut off the escape routes.

These days there are also CPU Sets

The classic affinity mask is a quite strong constraint.

Windows, meanwhile, also has a mechanism called CPU Sets.
CPU Sets is an API for the application to communicate its CPU preferences more softly.

In Microsoft’s description, CPU Sets are positioned as a “soft” affinity specification compatible with OS power management.

Do you want to pin CPUs strictly?
Or do you want to bias roughly where things run, while cooperating with OS power management and scheduling?

This distinction matters.

Rather than trying to solve everything with the old-school SetProcessAffinityMask, a modern Windows app needs to think in terms of CPU Sets and QoS as well.

4. P-cores/E-cores: “CPUs Have Personalities Too”

On recent CPUs, not all cores necessarily have the same performance and the same power consumption. The representative case is P-cores and E-cores; roughly speaking, P-cores lean toward performance and E-cores lean toward efficiency.

However, it is dangerous for a developer to casually hardcode “CPUs 0-7 are P-cores and 8-15 are E-cores.” The ordering of CPU numbers can vary with the CPU, the BIOS, the Windows version, firmware, OEM settings, and virtualization environments.

On the Windows side, the CPU Sets information includes a concept called EfficiencyClass.
On systems with heterogeneous processors, this value indicates the efficiency characteristics of that CPU Set. Microsoft’s documentation explains that a CPU Set with a higher value has a faster but less power-efficient processor.

If you want to work with P-cores/E-cores, looking at CPU numbers alone is not enough. To really nail it down, you need observations like these:

• Look at EfficiencyClass via the CPU Sets API
• Look at which CPU each thread executes on with Windows Performance Recorder / Analyzer
• Look at the trends in Task Manager’s logical processor view
• Measure processing times on each physical machine
• Compare AC power versus battery
• Compare across different power modes

P-cores/E-cores are not just a hardware specification — combined with the Windows scheduler, QoS, and power-saving settings, they determine where execution actually lands.

5. Power-Saving Settings Determine “How Hard the CPU Runs”

This part matters a great deal in the field.

Priority is “which thread runs first.”
Affinity is “which CPUs it may run on.”
P-cores/E-cores are “whether that CPU leans toward performance or efficiency.”

And the power-saving settings concern

what frequency and power state the CPU runs in to begin with

In other words, this can happen:

You raised the priority.
You steered onto the P-cores.
But if the power settings lean toward power saving,
the CPU may not run at full tilt.

This is a very Windows-flavored story.

On Windows 11, you can choose the power mode from the Settings app under “System > Power & battery.”
The labels vary by environment and version, but the directions are roughly these.

In addition, the long-standing power plans include Power Saver, Balanced, and High Performance.
Balanced adjusts performance and power consumption according to demand, while High Performance is the setting that trades power consumption for readily reaching maximum performance.

Even though the user-visible settings are simple, behind them sit the Processor Power Management (PPM) settings.

6. P-states, C-states, Boost, and EPP

A CPU does not always run at its maximum frequency; it has states for reducing power consumption.

P-states are the mechanism that lowers power consumption by changing the CPU’s frequency and voltage.
C-states are the mechanism by which the CPU shuts down some functions when idle and enters deeper power-saving states.

Windows power management uses these mechanisms to balance performance against power consumption.

That is why the phenomenon of “high priority but still slow” is entirely possible.

The thread is being executed preferentially.
But the CPU frequency is low.
Boost is hard to enter.
EPP leans toward power saving.
Core Parking limits the usable cores.
On battery, the whole OS leans toward power saving.

In cases like this, looking at priority alone will not get you to the cause.

Especially in periodic processing, image processing, instrument control, video processing, audio processing, USB camera capture, and serial communication, the problem is not just the average processing time but the “occasional lag.”

The average is fast.
But one run in a thousand lags.
That one run clogs the buffer.
The UI freezes.
The timing with the equipment slips.

For phenomena like this, the average CPU utilization is not enough.

You need to look at the distribution of processing times, the maximum, the outliers, the power state, the executing CPU, and the background load together.

7. Core Parking Affects “How Many Cores Are Usable”

Windows has a mechanism called Core Parking. It is a control that rests logical processors that are not in use.
When utilization is low, it shifts some cores toward low-power states to reduce power consumption.

In Microsoft’s documentation, CPMinCores is described as the setting that specifies the minimum percentage of logical processors that must be un-parked — that is, kept usable — at any given time.
Setting the value to 100% disables the Core Parking algorithm.

What becomes a problem here is the combination with affinity.

You constrained the threads with affinity: “run on this group of CPUs.”
But how power management treats those particular cores is a separate question.

Microsoft’s Windows Server documentation likewise explains that when active threads are strongly affinitized to a subset of CPUs within a NUMA node, there are situations where this fails to mesh with Core Parking’s decisions.

As a way of thinking, this is instructive for client PCs too.

Affinity constrains the scheduler.
Core Parking concerns which cores power management keeps in a usable state.

Think about these two separately and you will misread the cause.

8. EcoQoS / Efficiency Mode: Telling the OS “This Work Can Run Power-Efficiently”

In the old days, tuning Windows app performance mostly meant raising or lowering priority and changing affinity. Modern Windows, however, has a somewhat different concept as well. That is QoS.

QoS — Quality of Service — is the idea of indicating, per thread, “how performance-critical or how power-efficient this work should be.”

Microsoft’s documentation explains that while scheduling priority remains the primary input for deciding which thread runs next, QoS can influence core selection and processor power management.

In particular, EcoQoS is the mechanism for treating work whose performance is not paramount in a power-efficient way.

In C++, for example, you can put the current thread into EcoQoS using SetThreadInformation with ThreadPowerThrottling.

#include <windows.h>

void EnableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

Conversely, to return to performance-focused behavior, set StateMask to 0 for the same control target.

void DisableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = 0;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

EcoQoS is not a feature where “make everything power-efficient” is the right call. The work it suits looks like this:

• Background synchronization
• Low-priority index building
• Log aggregation that isn’t urgent
• Cache updates not directly tied to user interaction
• Maintenance work that just needs to finish eventually

On the other hand, you should be cautious with work like this:

• Processing directly tied to UI interaction
• Camera capture
• Audio processing
• Processing tied to a control cycle
• Pass/fail judgment in inspection equipment
• An export the user is waiting on
• Processing requiring near-real-time responses

Task Manager’s Efficiency mode is related to this same idea.
Microsoft’s Performance Diagnostics blog explains that enabling Efficiency mode lowers the process’s base priority to Low and sets its QoS to EcoQoS.

In other words, Efficiency mode is not just a “power-saving icon” — it is a mechanism that combines priority lowering with EcoQoS to protect the responsiveness of foreground apps and power efficiency.

From a developer’s perspective, this is quite important.

It enables a design where you can tell the OS not only “I want this work to finish fast” but also
“this work just needs to run without getting in the user’s way.”

9. A Decision Flowchart

Since the story so far is complicated, here is a decision flow for investigating performance issues and timing jitter in Windows apps.

flowchart TD
  A["Symptoms<br/>slow, jittery cycles, frozen UI, loud fan"] --> B["Record first<br/>processing time / max / CPU utilization / power state / AC or battery / target PC"]
  B --> C{"Is the CPU the main cause?"}

  C -- "No / unknown" --> D["Check I/O, locks, DB, network, GC, GPU, drivers<br/>eliminate the waits before touching priority or affinity"]
  C -- "Yes" --> E{"Is there heavy CPU contention with other processes?"}

  E -- "Yes" --> F["Consider priority<br/>but limit the scope<br/>avoid routine use of High/Realtime"]
  E -- "No" --> G{"Is execution skewed toward specific CPUs?"}

  G -- "Yes" --> H["Check affinity / CPU Sets<br/>are you pinning too hard<br/>are you accounting for P/E cores and NUMA"]
  G -- "No" --> I{"Are frequency or power states suspicious?"}

  I -- "Yes" --> J["Check power mode / power plan / PPM<br/>suspect P-states / EPP / boost / Core Parking"]
  I -- "No" --> K{"Is background work disturbing the foreground?"}

  K -- "Yes" --> L["Consider EcoQoS / Efficiency Mode / lowering priority<br/>shift non-urgent work to the power-efficient side"]
  K -- "No" --> M["Revisit the algorithm, parallelism, queue design, and UI thread design"]

  F --> N["Change one item at a time and A/B measure"]
  H --> N
  J --> N
  L --> N
  M --> N

  N --> O["Look not just at the average but at<br/>maximums, outliers, heat, and the impact on other apps"]

What matters in this flow is not fiddling with settings from the start. Record first.

• Is it always slow?
• Or only occasionally slow?
• AC power or battery?
• What is the power mode?
• Is it in Efficiency mode in Task Manager?
• Is CPU utilization high?
• Is the frequency rising?
• Which thread is using the CPU?
• How large is the maximum processing time?
• Is other resident software or antivirus software involved?

Then change things one at a time.

Change the priority.
Change the affinity.
Change the power mode.
Apply EcoQoS.
Separate out the background processing.
Insert a queue.
Move it off the UI thread.

Change several at once, and you will no longer know what worked.

10. Commands for Checking in the Field

When a Windows app behaves differently depending on the environment, it helps to be able to capture the state first.

View CPU information

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

View the active power plan

powercfg /getactivescheme

View the processor power management settings

powercfg /q SCHEME_CURRENT SUB_PROCESSOR

The output is quite long, but you can check the settings related to minimum/maximum processor state, EPP, boost, and Core Parking.
The visible items vary by environment.

Generate a power efficiency diagnostics report

Run in an elevated terminal.

powercfg /energy

After measuring for a fixed period, an HTML report is produced.
It is an entry point for looking at drivers, devices, timer resolution, USB power saving, sleep blockers, and so on.

View the priority and affinity of a target process

Get-Process -Name MyApp |
  Select-Object Id, ProcessName, PriorityClass, ProcessorAffinity

View the CPU’s performance state

The available counter names vary by environment, but these Performance Counters are a useful reference.

Get-Counter '\Processor Information(_Total)\% Processor Performance'

Get-Counter '\Processor Information(_Total)\% Processor Utility'

For serious investigation, capturing ETW with Windows Performance Recorder and Windows Performance Analyzer is more reliable.
You can track cycle jitter, context switches, the executing CPU, DPC/ISR, disk I/O, and CPU frequency changes all together.

11. For Soft Real-Time Work, Consider Everything Together

Windows is not a real-time OS in the usual sense. Yet Windows apps in the field are sometimes asked for near-real-time characteristics.

• Capturing images from a USB camera on a fixed cycle
• Exchanging data with equipment over serial communication
• Reading data from measuring instruments
• Synchronizing with PLCs and external devices
• Processing audio or video
• Returning inspection results within a fixed time
• Running heavy computation without freezing the UI

For work like this, fast code alone is not enough.

You need thread design.
You need queue design.
You need logging.
You need timeouts.
You need backpressure.
You need to decide whether to drop, wait, or retry when things run late.

And on top of all that, you need to look at priority, affinity, P-cores/E-cores, and power-saving settings.

For example, consider a camera capture thread.

This thread is close to user interaction and has periodicity.
Perhaps it should not be EcoQoS.
Perhaps it is worth raising its priority slightly.
But raise it too far and the UI and other processing suffer.
Pinning the affinity might stabilize it.
But if the pinned target leans toward E-cores, it might backfire.
If the power mode leans toward power saving, it might lag only on battery.

What about compressing old logs, on the other hand?

That may be processing no user is waiting on.
In that case, lower its priority.
Make it EcoQoS.
Run it at idle.
Run it only on AC power.
A design like that is kinder for the app as a whole.

Rather than making everything “fast,” separate the work that should be fast from the work that should stay out of the way.

12. Basic Design Principles

There are six basic principles for handling these matters in a Windows app.

1. Don’t pin things from the start

It is better not to strongly fix priority or affinity from the start.

The Windows scheduler does a rather good job most of the time.
Imposing needless constraints from the app side can make things worse.

Build it normally first.
Measure.
When a problem appears, form a hypothesis.
Make a small change.
Measure again.

That is the order.

2. Use priority temporarily

Keep high priority to just the intervals that need it.

Rather than staying at high priority permanently,

raise it just before the important work
restore it when done

is safer.

3. Consider affinity near the end

Affinity is a strong setting.

It can be effective when cycle jitter or the effects of CPU migration are suspected.
But it is not the first setting to touch.

In particular, if your customers have multiple kinds of PCs, hardcoding CPU numbers is dangerous.

4. Don’t hardcode P-cores/E-cores — observe them

If you want to use P-cores and E-cores selectively, observe on real machines first.

Rather than hardcoding by CPU number, look at CPU Sets, EfficiencyClass, ETW, and actual measurements.

5. Test with power-saving settings as a premise

“It’s fast because the development machine is on AC power with high-performance settings” is not enough.

In customer environments, states like these are entirely normal:

• A laptop running on battery
• Best power efficiency
• Energy saver
• OEM-specific power-saving utilities
• Power settings locked down by corporate policy
• Thin PCs that throttle under heat
• Business terminals loaded with resident software

In performance testing, you want to examine at least these conditions separately.

6. Consider EcoQoS for background processing

For work not directly tied to the user experience, it is often better to prioritize staying out of the way over chasing performance.

An app that runs everything at high performance may be fast.
But it disturbs other work.
It spins up the laptop’s fans.
It drains the battery.
The result is an app that is unpleasant to use.

For Windows apps, “coexisting well” is part of quality, not just speed.

13. Common Misconceptions

Raising priority makes it faster

Not necessarily.

If CPU contention is the cause, it can work.
But if the cause is I/O waits, lock waits, low frequency due to power saving, or execution on the E-core side, priority alone is insufficient.

Pinning to P-cores is always the right answer

Not always.

P-cores are high performance, but heat and power consumption increase too.
They may also contend with other important foreground work.

What matters more is separating the work that should go to P-cores from the work for which E-cores are sufficient.

Power-saving settings are the user’s preference and irrelevant to the app

They are relevant.

The same app executes differently depending on the power mode, power plan, EPP, boost, and Core Parking.

On laptops especially, behavior changes between AC power and battery.

Efficiency mode just makes things slower

It does not just make things slower.

Through priority lowering and EcoQoS, it is a mechanism for protecting foreground app responsiveness and power efficiency.
For non-urgent background work, it is worth considering proactively.

Windows is just inherently unstable

That, too, is a sloppy view.

Windows is not a real-time OS.
But if you understand scheduling, power management, QoS, measurement, logging, and thread design, you can stabilize it substantially for field use.

The problem is not “it’s impossible because it’s Windows” — it is not looking at what is happening in which layer.

14. Design the Logging Before the Implementation

Problems of this kind sometimes occur only in customer environments. So it helps to make the app capable of recording at least minimal diagnostic information.

For example, the diagnostic log should include information like this:

• App version
• Windows version
• CPU name
• Number of logical processors
• AC power or battery
• Average, maximum, and percentiles of processing time
• Number of delayed processing cycles
• Priority of the target thread
• Process priority
• Whether affinity is set
• Whether EcoQoS is set
• Power plan at startup
• Number of times the target processing timed out

When a customer says “it’s occasionally slow,” with no records you are left to a battle of guesses. With logs, you can form hypotheses.

Slow only on battery
Slow only on a specific PC
Slow only right after startup
Slow starting 30 minutes in
Slow only while another app is running
Outliers appearing at a fixed cycle

Once differences like these are visible, it becomes much easier to determine whether it is priority, affinity, power settings, heat, or some other wait.

15. The KomuraSoft Perspective

In Windows app development, clean theory alone is not enough.

Working on the customer’s PC.
Working on the terminals in the field.
Coexisting with old peripherals.
Working in environments with antivirus software, printers, and corporate policies.
Not falling apart under a laptop’s power-saving settings.
Delivering real performance where performance is needed.
Staying out of the user’s way for work that isn’t urgent.

To achieve that, it is better not to see Windows as a mere “black-box OS.”

Windows is thinking about how to run your threads.
It is thinking about which CPU to run them on.
It is balancing power against performance.
It is handling heterogeneous cores like P-cores and E-cores.
It is trying to distinguish foreground apps from background work.

Developers should not fight that — they should communicate their intent where it is needed.

This work is keeping the user waiting.
This work can be somewhat slow.
This work’s cycle timing is critical.
This work just needs to run quietly in the background.
This work must not disturb other work.

You translate that design into your understanding of priority, affinity, QoS, and power-saving settings.

16. Conclusion

The performance of a Windows app is not determined by code alone.

Raise the priority, and it may still not behave as expected if affinity has steered it toward the E-cores.
Steer onto the P-cores, and the CPU may still not deliver maximum performance if the power mode leans toward power saving.
Apply strong affinity without considering CPU Sets and QoS, and you may cut off the escape routes of Windows’s power management and scheduler.
Push everything to the high-performance side, and heat, fan noise, battery drain, and the impact on other apps all increase.

In Windows app development, you need to design not just for speed but for responsiveness, stability, power consumption, heat, and coexistence with other processes.

And the things to look at remain these four:

Priority
Affinity
P-cores / E-cores
Power-saving settings

And on modern Windows, EcoQoS and Efficiency mode join them.

There is plenty to worry about.

But there is no need to leave the worry as anxiety.

Turn the worry into measurement.
Turn the worry into logs.
Turn the worry into design.
Turn the worry into test conditions.

Do that, and Windows becomes not a capricious execution environment but a platform for the field that rewards careful observation.

Windows is not a real-time OS.
Even so, if you understand the execution environment and design for it, you can build apps that are thoroughly dependable in the field.

And that very difficulty is part of what makes Windows app development interesting.

Reference Links

• The complete sample code for this article (C# / PowerShell / unit tests) - komurasoft-blog-samples (GitHub)
• Scheduling Priorities - Microsoft Learn
• SetProcessAffinityMask function - Microsoft Learn
• SetThreadAffinityMask function - Microsoft Learn
• CPU Sets - Microsoft Learn
• SYSTEM_CPU_SET_INFORMATION structure - Microsoft Learn
• Change the power mode for your Windows PC - Microsoft Support
• Power Policy Settings - Microsoft Learn
• P-states and C-States - Microsoft Learn
• Processor power management options - Microsoft Learn
• CPMinCores - Microsoft Learn
• Quality of Service - Microsoft Learn
• SetThreadInformation function - Microsoft Learn
• Reduce Process Interference with Task Manager Efficiency Mode - Microsoft DevBlogs

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.