Solved Severe DPC Latency on OptiPlex 7020 (i5-14500) Triggered by Screen Off – ACPI.sys 80ms Spike (25H2)

Hi everyone,

I am a non-native English speaker writing with translation assistance.

This issue is 100% reproducible and appears tied specifically to Screen Off (S0 idle) events on Windows 11 25H2.


System:
- Dell OptiPlex 7020 SFF
- Intel Core i5-14500 (14th Gen)
- BIOS v1.23.1
- Windows 11 25H2 (clean install)

The Issue:
System responsiveness degrades progressively over time, triggered specifically by display power-off (Screen Off).
Eventually, even simple UI actions such as Explorer context menus lag for several seconds.

A reboot temporarily restores normal behavior, confirming the accumulative nature of the issue.


Screenshot: ACPI.sys (ACPIDevicePowerDpc) showing ~80ms DPC execution during Screen Off, correlated with UI lag

The spike corresponds to ACPIDevicePowerDpc in ACPI.sys, reaching ~80ms execution time.

Reproduction Steps:
1. Clean install Windows 11 25H2
2. Leave system idle until display turns off
3. Repeat several Screen Off / Wake cycles
4. Observe increasing UI lag and DPC latency spikes


WPA Analysis (Clean Environment):
- Module: ACPI.sys
- Function: ACPIDevicePowerDpc
- Max Duration: 80.896 ms
- Chain Reaction: Causes 45ms+ delays in storport.sys

Impact:
- Severe UI lag (Explorer, context menus)
- I/O stalls
- System becomes nearly unusable until reboot

Workarounds:
- Disable Screen Off → Issue disappears completely
- Set CsEnabled=0 → Reduces spikes
- Fix timer resolution (0.5ms) → Reduces accumulation

Important Observations:
- Reproduces on 10+ identical units
- Occurs ONLY on Windows 11 25H2
- Does NOT occur on 24H2 with same hardware/BIOS
- Clean OS with no third-party software

Technical Assessment:
An 80ms DPC at DISPATCH_LEVEL is not acceptable under any normal condition.

The behavior strongly suggests a firmware-level issue in ACPI (AML), possibly involving a busy-wait or failed handshake during D3 power state transitions triggered by Screen Off.

Given the strict reproducibility and OS dependency, this appears to be an interaction issue between firmware and the updated Windows 11 25H2 power management stack.

Question:
Has anyone observed similar behavior on Intel 14th Gen platforms or Dell systems?

Any insights on confirming and escalating this as a firmware-level issue would be greatly appreciated.

Hello and welcome to the forum. As users, to get to Microsoft about our only way to report issues is through the Feedback Hub which is in your start menu.
However, Microsoft does pay attention to the OEMs. I think this would be one that would have to be escalated through the Dell side of things. Getting past Dell's lower level support is very difficult and time consuming, but can be done if you are tenacious and demanding enough. It is a little easier if your device is still under warranty. Once you do get to Dell's 3rd level of support, and prove your point, they take an issue and run with it.

I would also post this issue on the Dell Forum along with your research. That forum is actively monitored by Dell.

glasskuter said:

Hello and welcome to the forum. As users, to get to Microsoft about our only way to report issues is through the Feedback Hub which is in your start menu.
However, Microsoft does pay attention to the OEMs. I think this would be one that would have to be escalated through the Dell side of things. Getting past Dell's lower level support is very difficult and time consuming, but can be done if you are tenacious and demanding enough. It is a little easier if your device is still under warranty. Once you do get to Dell's 3rd level of support, and prove your point, they take an issue and run with it.

I would also post this issue on the Dell Forum along with your research. That forum is actively monitored by Dell.

Click to expand...

Thank you for the quick reply and advice, glasskuter.


I appreciate your suggestion. I have already reported this issue through Dell ProSupport (with detailed WPA analysis) and also posted on the Japanese Dell Community forum.


Since this appears to be a combination issue between Windows 11 25H2 power management changes and Dell/Intel firmware behavior (especially ACPI power state transitions), I believe escalation through Dell would be the most effective path.


Would it still be worth submitting via Feedback Hub in parallel?Or is it better to focus on pushing Dell's support to escalate internally to their 3rd level engineering team?


Also, if anyone else has experienced similar ACPI.sys!ACPIDevicePowerDpc spikes (80ms+) triggered by screen-off on 13th/14th gen Intel systems, I would be very interested to hear your experiences.


Thanks again for your input.

While I believe the OEM approach would be more appropriate and effective, it can't hurt to post on Feedback Hub too.
Good luck with Dell, I had a problem back in 2020 on a new Dell which kept going around in circles in level 2 support for 6 months. They changed my motherboard twice. Out of frustration I wrote a letter directly to Michael Dell's Office. Within a week, an engineer called me. Within 2 weeks, a new bios update fixed the problem.

glasskuter said:

While I believe the OEM approach would be more appropriate and effective, it can't hurt to post on Feedback Hub too.
Good luck with Dell, I had a problem back in 2020 on a new Dell which kept going around in circles in level 2 support for 6 months. They changed my motherboard twice. Out of frustration I wrote a letter directly to Michael Dell's Office. Within a week, an engineer called me. Within 2 weeks, a new bios update fixed the problem.

Click to expand...

Thank you again for the detailed advice and for sharing your personal experience, glasskuter.
I really appreciate it.
I’ll follow your suggestion and submit the issue through Feedback Hub as well, while continuing to work with Dell ProSupport for escalation.
Your story about writing directly to Michael Dell’s office and getting a BIOS update within two weeks is very encouraging. It gives me hope that persistence can lead to a real solution.
I also hope that this discussion will eventually help other users in Japan and elsewhere who might be facing the same issue.
Thank you once more for taking the time to reply. I’ll keep the thread updated if there are any developments.
Best regards,

Update: Automated Test Result with PowerShell Script (10 Screen-Off Cycles)


I wrote a simple PowerShell script that automatically triggers screen-off every 60 seconds (1 minute) for 10 cycles.


Here is the WPA analysis result:



The result shows a very clear and consistent pattern:


- ACPI.sys!ACPIDevicePowerDpc spikes to ~85ms every single time.- The spikes are remarkably regular, almost like a heartbeat pattern triggered specifically by the screen-off event.


This strongly suggests the delay is caused by the power state transition itself, rather than random software activity.


@glasskuter - Thank you again for your helpful advice earlier. I am planning to submit this through Feedback Hub as well, and I will continue working with Dell ProSupport for escalation.


If anyone else has seen similar consistent ~85ms ACPI DPC spikes on 13th/14th gen Intel systems during screen-off transitions, I would appreciate any insights.


Thanks!

For reference, here is the original (unannotated) WPA view of the same trace.

The periodic pattern and the ACPIDevicePowerDpc spikes can be observed consistently without any highlighting.

Summary Update: Since this thread has grown, I am consolidating the key findings and automated test results here for clarity.

I am experiencing consistent DPC latency spikes on multiple OptiPlex 7020 systems (Core i5-14500) running Windows 11.

The Symptom:After the screen turns off or transitions through power-saving states, the system becomes sluggish. Simple operations, such as right-clicking in File Explorer, can take several seconds to respond.

Key Test Results (Automated):To isolate the issue, I ran a PowerShell script that toggles the screen-off state every 60 seconds for 10 cycles.WPA analysis reveals:

• ACPI.sys!ACPIDevicePowerDpc spikes to ~85ms with 100% reproducibility.
• The spikes follow a consistent "heartbeat" pattern tied to the power state transition.

Graph:



Conclusion & Status:The consistency of these ~85ms spikes strongly suggests a firmware/BIOS-level issue related to power state transitions, rather than random software interference.

I have already reported this to Dell ProSupport with detailed WPA traces and am pushing for escalation. I also plan to submit this via Feedback Hub.

If anyone has encountered similar ACPI DPC spikes on 13th/14th Gen Intel systems during power transitions, please share your findings.

Best regards,

(Optional: non-native speaker disclaimer here)

Additional trace showing the correlation between CPU power state transitions and DPC activity.

Here is a more detailed WPA view:



- Top graph: CPU Idle States (C-state transitions)
- Bottom graph: DPC/ISR Duration by Module & Function

Spikes in **ACPI.sys!ACPIDevicePowerDpc** (~80–90ms) appear to align with periodic power state transitions, including those associated with Screen Off events.

This view may help illustrate the structural relationship between power transitions and the observed latency buildup.

In addition, DPC activity from Intel storage-related routines (e.g., RaidAdapterRedirectDpcRoutine) can be observed around the same timing, suggesting potential downstream impact on the storage stack, though the exact relationship would require further analysis.

I am also in ongoing contact with Dell ProSupport regarding this issue and will share any updates if new findings become available.

Any insights from others who have analyzed similar power transition-related DPC patterns on 13th/14th gen Intel platforms would be appreciated.

**Dell Official Response Summary**


Dell ProSupport has provided a formal response.


According to them:- This issue is not due to a hardware defect in individual units.- It is considered a "platform-wide characteristic" related to the design of Modern Standby power management.- It is not classified as a bug or fault, and there are no plans for a specific fix.- As a mitigation, they suggest that adjusting screen-off frequency and power settings may help reduce the perceived impact.


This reflects Dell’s current official position on the matter.

Final Update: Dell’s Official Response and the "Triple Bacon Deluxe" Tragedy

After months of investigation, automated testing, and detailed WPA analysis, we have reached the final conclusion for this case.

• The Findings: Consistent ~85ms ACPI.sys!ACPIDevicePowerDpc spikes occur every time the screen turns off.
• The Correlation: These spikes reliably correlate with CPU C-state transition failures and delays in storport.sys + Intel iaLPSS2i drivers.
• The Root Cause: The high regularity of this pattern indicates a structural mismatch in power state transitions within the firmware logic.

I received the official stance from Dell’s engineering support: They have classified this behavior as "By Design" within the Modern Standby environment and will not be treating it as a bug or targeting it for a fix.

To wrap this up, I’d like to share a little analogy that perfectly captures the current state of "Modern" PC environments.

---

The Tragedy of the "Triple Bacon Deluxe"​

Imagine a massive fast-food headquarters (Microsoft) mandates a new, incredibly complex menu item for every franchise: the "Triple Bacon Deluxe" (Modern Standby). This burger requires precise timing, multi-layered heat control, and delicate synchronization to execute.

However, the kitchen equipment at one specific franchise (Dell) was built with an older design that only understands "Low, Medium, and High" heat. As a result, every time they try to cook this new flagship burger, the entire kitchen freezes for 90 seconds (the 90ms DPC spike) while the chef struggles with the heat transition.

When I asked the manager, "Why is my order constantly delayed?" he looked at the corporate posters on the wall and whispered:"Sir, that's our 'Signature Slow-Cooked Flavor' (The Specification). If you're in a hurry, we can always make it a 'Single Bacon' for you (by keeping your screen always on)."

Suggesting we remove the very ingredients that define the "Modern" experience just to make the kitchen function—well, that’s quite a self-defeating strategy, isn’t it?

---

Closing Thoughts​

This investigation wasn't about pointing fingers, but about understanding the gap between platform requirements and actual firmware behavior. Unfortunately, the manufacturer has chosen to accept this gap as a "feature."

I want to thank everyone who contributed to this thread—especially @glasskuter for the practical advice. If you are dealing with similar latency issues on 13th/14th Gen Intel systems, please feel free to reference this data.

This will be my final post on the topic.Thank you all.

As a brief note, the behavior has been narrowed down to a platform-level power transition interaction (ACPI/C-state), based on consistent traces and vendor feedback.

Update: Research Conclusion & Transition to Project Evaluation

Hello everyone,

I wanted to provide a final update on this investigation regarding the 80ms ACPI.sys spikes on the OptiPlex 7020 (Intel 14th Gen).

After deep-diving into DSDT/ASL analysis and comparing behaviors across different vendors, it has become evident that this is not a simple driver bug but a structural issue in how Windows handles Modern Standby transitions. The OS lacks a proper "budgeting" or "timeout" mechanism for heavy AML methods, leading to these "silent" spikes that bypass the DPC Watchdog.

Since this discussion has identified the root cause as a fundamental OS/Firmware design gap, I have moved the focus of this research to a dedicated GitHub project to systematically evaluate stability across different hardware:

windows-pc-stability-evaluation

I will be marking this thread as "Solved" to signify that the diagnostic phase is complete. I invite anyone interested in further data collection or technical deep-dives to join the project on GitHub.

Thank you for all the help and suggestions throughout this thread!