Hello @Denis Bakharev
The SleepStudy result is useful, but don't disable the Microsoft Store service or manually remove WinStore.Tasks.OfferNotificationsTask yet.
Microsoft Store apps can perform certain background tasks during Modern Standby. Windows is supposed to manage and constrain that activity so the system can subsequently return to its lowest-power state (DRIPS).
The important question, therefore, isn't simply whether Microsoft.WindowsStore appears as an offender, but how long it keeps the system active and whether the system eventually reaches DRIPS.
In the affected SleepStudy session, expand the session details and check:
- % LOW POWER STATE TIME
- the duration attributed to Microsoft.WindowsStore
- whether WinStore.Tasks.OfferNotificationsTask remains active for most/all of the Screen Off period
- whether this happens on AC power, DC power, or both
Microsoft specifically recommends powercfg /sleepstudy as the starting point for diagnosing components preventing a Modern Standby system from reaching its lowest power state.
Run these from an elevated Command Prompt immediately after reproducing the problem:
powercfg /requests
powercfg /sleepstudy /duration 7
The seven-day report helps here because it shows whether this is an isolated Store maintenance/notification event or a recurring pattern.
One other detail matters: AC versus battery operation. Microsoft documents that Modern Standby permits more background/maintenance activity while connected to AC power, whereas activity is more restricted on battery. Store-app background activity can therefore look quite different between the two states.
If the Store task continuously prevents DRIPS for an extended period on battery power, particularly across multiple standby sessions, consider that abnormal rather than expected Store background activity.
Since you're running Windows 11 IoT Enterprise LTSC 10.0.26100.9168, avoid removing/re-registering the Store package or disabling Store infrastructure as the first workaround. That can affect servicing and other packaged applications without addressing the underlying Modern Standby problem.
If possible, please share the expanded SleepStudy section for one affected session showing the Active Time, Low Power State Time/DRIPS percentage, duration, and Top Offenders. That should tell us whether OfferNotificationsTask is genuinely blocking low-power idle or is simply being reported as activity during a normal Modern Standby transition.
References:
Modern Standby SleepStudy
Integrating apps with Modern Standby
Modern Standby diagnostic tools
Modern Standby
Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.