Forum Widgets
Latest Discussions
Win 10/11 file history is malfunctioning after an update why hasn't Microsoft fixed this issue yet?
Hello, I would like to ask whether other Windows 10/11 users have experienced the same File History problem. I also hope the Microsoft technical team can seriously investigate this issue. My laptop is running Windows 11 25H2. Before installing KB5101684, File History had always worked normally. In Control Panel → All Control Panel Items → File History, the backup time would update normally whenever files were backed up to my D: drive. Around July 28–29, 2026, at approximately 10:00 AM, before KB5101684 was installed, File History was still working normally. I want to make this very clear: I did not manually change my File History settings, delete Event Viewer entries, or modify or delete relevant registry settings. The problem started after KB5101684 was installed. I have already confirmed the following: File History is still enabled. The D: drive is working normally and can be accessed without any problems. After selecting Control Panel → All Control Panel Items → File History → Run now, files are indeed written to: D:\FileHistory\user\LAPTOP-GJTRIQFJ\Data\C\Users\user However, the "Last backup" time displayed by File History does not update correctly. Even after modifying a document, confirming that it was successfully saved, and then clicking Run now, the latest backup time and file versions do not update as expected. Under File Properties → Previous Versions, it still says: "There are no previous versions available." I also noticed that every time a backup runs, folders such as Desktop and Favorites under the FileHistory folder on the D: drive continue to have their modification dates changed, even when their contents have not actually been modified. What makes this even more concerning is that my Windows 10 22H2 desktop computer also started experiencing File History synchronization problems after installing KB5120249. In other words: Windows 11 25H2 → KB5101684 → File History problem Windows 10 22H2 → KB5120249 → File History problem This makes me seriously concerned that these problems may be related to a recent Windows Update change or regression affecting File History. To be honest, I am extremely frustrated with Microsoft. The problem is not simply that Windows has a bug. Any large operating system can have bugs. The real problem is that users have reported the issue, provided detailed testing results, identified the Windows versions and specific KB updates involved, provided the actual File History paths, and spent considerable time troubleshooting, yet it is already August and there still does not appear to be a clear official confirmation from Microsoft regarding whether these issues are related to KB5101684 or KB5120249. Users should not have to repeatedly troubleshoot the same problem without receiving a clear explanation or effective solution. I would like the Microsoft technical team to seriously investigate the following: Could KB5101684 be causing File History backup timestamps or version information to behave incorrectly on Windows 11 25H2? Could KB5120249 be causing similar File History problems on Windows 10 22H2? Why are files actually being written to the FileHistory directory while the "Last backup" time does not update correctly? Why does "Previous Versions" continue to report that no previous versions are available? Why do folders such as Desktop and Favorites have their modification dates changed during backup even when their contents have not been modified? Could this be a File History regression introduced by a recent Windows Update? Please do not simply ask users to repeatedly reset File History, reselect the backup drive, or recreate the File History configuration without investigating the underlying cause. Microsoft needs to determine what is actually happening. I would also like to ask other Windows 10/11 users who have experienced similar File History problems to leave a comment with the following information: Windows version KB update number Date when the problem started Whether the backup location is a local drive or network drive Whether the "Last backup" time is incorrect Whether "Previous Versions" is unavailable Whether files are still being written to the FileHistory folder Please also consider sharing this post or bringing it to the attention of other Windows users and the Microsoft technical team. The more independent cases Microsoft can compare, the easier it should be to determine whether this is a common problem. I am not asking Microsoft to guarantee that Windows will never have bugs. I am asking Microsoft to properly investigate problems that users have clearly reported, provide an explanation, and deliver an actual fix when appropriate. This issue has now continued into August, and I am extremely disappointed with the way the File History problem has been handled so far. Microsoft, please do not ignore this issue. Please investigate it seriously and provide users with a clear response and an actual solution. Thank you.
Windows Update not installing
I have been in the Beta version of Windows for years now and I am the administrator. Today was was trying to finally update Windows to the latest updates. I was able to download 9202 and it says was installed than when I tried to install another update 9209 it went completely through the download process but when I went to installed it it says I cant, because I need to go to the diagnostic section and toggle On, but when I try to toggle on nothing happens and it stays in the Off position. It also says that if I don't get permission from my administrator I won't be able to get any further updates and I should leave the Program. When I check it says I signed in correctly and that I am the adminstrator and there is no one else. I don't have any idea what to do to solve this.[GSOD]SYSTEM_SERVICE_EXCEPTION in win32kfull!SetMagnificationInputTransform when a process exits
问题概述 Windows 11 Insider Experimental 26H2 Build 26340.9233 连续发生两次绿屏崩溃。 两份 minidump 经 WinDbg 分析后指向完全相同的故障函数、调用栈、触发进程及故障哈希。崩溃发生在 Windows 销毁进程关联的桌面对象，并清理屏幕放大输入变换状态时。 系统环境 操作系统：Windows 11 Pro for Workstations Insider 通道：Experimental 显示版本：26H2 完整系统版本：26340.9233 BuildLabEx：26100.6.amd64fre.ge_release_flt.260716-1700 系统架构：x64 win32kfull.sys 版本：10.0.26100.9233 BIOS Revision：1.42.0.0 Hyper-V：已启用 故障现象 系统显示绿色停止错误画面并自动重启： Stop code：SYSTEM_SERVICE_EXCEPTION Bugcheck：0x0000003B Exception code：0xC0000005 What failed：win32kfull.sys 该问题在同一天连续发生两次，并分别生成以下转储： 082226-21906-01.dmp 082226-21734-01.dmp WinDbg 分析结果 两份转储的分析结果一致： BUGCHECK_CODE: 3b BUGCHECK_P1: c0000005 PROCESS_NAME: codex-command-runner-0.149.0-alpha.4.1.exe FAILURE_BUCKET_ID: AV_win32kfull!SetMagnificationInputTransform FAILURE_ID_HASH: {527223d9-4b8b-e502-e7e6-16fc4649fd38} SYMBOL_NAME: win32kfull!SetMagnificationInputTransform+39 IMAGE_NAME: win32kfull.sys IMAGE_VERSION: 10.0.26100.9233 故障指令： win32kfull!SetMagnificationInputTransform+0x39: mov rbx, qword ptr [rax+1F0h] RAX = 0000000000000000 这表明内核代码尝试通过空指针读取内存，从而触发 0xC0000005 访问冲突。 关键调用栈 nt!NtTerminateProcess nt!PspExitThread nt!PspExitLastThread nt!PspRundownSingleProcess nt!ObKillProcess nt!ExSweepHandleTable nt!ExpWin32CloseProcedure win32k!W32CalloutDispatchThunk win32kbase!W32CalloutDispatch win32kfull!UnmapDesktop win32kfull!DestroyDesktop win32kfull!zzzDecomposeDesktop win32kfull!MagpDecomposeDesktop win32kfull!MagpRevokeInputTransfrom win32kfull!CancelMagnificationInputTransform win32kfull!SetMagnificationInputTransform+0x39 从调用栈判断，崩溃发生在以下过程中： codex-command-runner 进程退出； Windows 清理该进程及其桌面对象； win32kfull.sys 撤销 Magnification Input Transform； SetMagnificationInputTransform 解引用空指针； 系统触发 SYSTEM_SERVICE_EXCEPTION。 重复性 两次崩溃均具有以下共同点： 相同停止代码和异常类型； 相同故障函数及函数偏移； 相同的空指针访问方式； 相同触发进程及版本； 相同桌面销毁和放大输入变换清理调用栈； 相同 Failure ID Hash。 因此，该问题具有较强的可重复性，不像随机硬件错误。 目前尚未完全确定具体的用户操作序列，但两次均发生在 Codex 桌面应用的本地命令运行器退出期间。该进程看起来是触发场景；实际非法访问发生在 Windows 内核的 win32kfull.sys 中。 预期行为 任何普通用户态进程退出或其桌面对象被销毁时，Windows 都应安全清理 Magnification Input Transform 状态。即使相关状态不存在、已经释放或不完整，也不应发生内核空指针访问或导致整个系统崩溃。 实际行为 win32kfull!SetMagnificationInputTransform 在桌面销毁路径中收到或获取了空对象，但没有在访问对象偏移 0x1F0 前进行有效性检查，最终导致系统级崩溃。 希望微软协助调查 请重点检查 Build 26340.9233 中以下方面： SetMagnificationInputTransform 的对象生命周期和空指针检查； CancelMagnificationInputTransform 与 MagpRevokeInputTransfrom 的重复撤销或竞态条件； 临时桌面、隔离桌面或进程退出时的 DestroyDesktop 清理路径； Experimental 26340 系列中 Magnifier 相关改动是否影响输入变换状态； 短时间内创建并销毁桌面的应用是否能够稳定触发该问题。 English engineering summary Two independent minidumps from Windows 11 Insider Experimental Build 26340.9233 show an identical SYSTEM_SERVICE_EXCEPTION (0x3B) with 0xC0000005. The crash occurs at: win32kfull!SetMagnificationInputTransform+0x39 mov rbx, qword ptr [rax+1F0h] RAX = 0 Both dumps have the same process, stack, failure bucket and failure hash: PROCESS_NAME: codex-command-runner-0.149.0-alpha.4.1.exe FAILURE_BUCKET_ID: AV_win32kfull!SetMagnificationInputTransform FAILURE_ID_HASH: {527223d9-4b8b-e502-e7e6-16fc4649fd38} The process is terminating, Windows destroys its associated desktop, and the kernel crashes while revoking the Magnification Input Transform: NtTerminateProcess → PspRundownSingleProcess → ExpWin32CloseProcedure → UnmapDesktop → DestroyDesktop → MagpDecomposeDesktop → MagpRevokeInputTransfrom → CancelMagnificationInputTransform → SetMagnificationInputTransform → NULL pointer dereference Please investigate the object lifetime, synchronization and null validation in the Magnification Input Transform cleanup path when a temporary or isolated desktop is destroyed.win 11 25H2 KB5101684 Preview and win 10 22H2 KB5120249 issue
Hi everyone, I’m wondering if anyone else is experiencing the same File History problems on Windows 10 or Windows 11. My laptop is running Windows 11 25H2. Before installing KB5101684, File History worked normally. After installing the update, I started noticing several strange problems: The Last backup time does not update correctly. Previous Versions still shows no new versions. Files are still being written to D:\FileHistory\..., but File History does not properly update its backup information. Folders such as Desktop and Favorites can have their modification dates changed even when I did not actually change their contents. I did not manually change File History settings, registry settings, or delete Event Viewer entries. I also experienced a similar problem on my Windows 10 22H2 desktop after installing KB5120249. So my situation is: Windows 11 25H2 → KB5101684 → File History problem Windows 10 22H2 → KB5120249 → File History problem At this point, I have to ask: Could these Windows updates have introduced a File History regression? I have already reported this to Microsoft This is the part that is really frustrating. I have already reported the problem through the Feedback Hub, and I also contacted Microsoft Support and chatted online with a support professional. I was told that the issue would be handled and looked into. But now several days have passed, and I still have not received any meaningful follow-up or explanation. So honestly, I have to ask: What exactly is Microsoft doing with this report? If Microsoft tells users that the issue will be handled, then users should at least receive some kind of follow-up. Instead, it feels like the report disappears into a black hole. I have already spent a lot of time checking File History settings, services, the backup drive, and the actual files being written to the FileHistory folder. I have also provided detailed information about when the problem started and which Windows updates were installed. At this point, simply telling users to reset File History or reselect the backup drive is not good enough. Those may be temporary workarounds, but they do not answer the fundamental question: Why did File History start behaving incorrectly after the Windows update? If File History worked correctly before the update and then started showing incorrect backup timestamps, missing Previous Versions, and other abnormal behavior afterward, Microsoft should investigate the update itself. Microsoft needs to take this seriously A backup system is not something users can afford to treat casually. If File History is still copying files into the backup folder while the File History interface and Previous Versions do not correctly reflect the actual backup state, users can easily be misled into thinking their backups are working properly when they are not. That is a serious reliability issue. Microsoft should investigate whether KB5101684 and KB5120249 introduced a regression affecting File History, including: Incorrect backup timestamps Missing Previous Versions Incorrect modification dates File History database/catalog problems Unexpected or repeated backup behavior I am not asking Microsoft to magically fix my computer without investigation. I am asking Microsoft to actually investigate the Windows update and determine whether it caused the regression. I have already used the Feedback Hub. I have already contacted Microsoft Support. I have already spoken with a support professional online. I was told that the issue would be handled. win 10/11 C:\Users\User\AppData\Local\Microsoft\Windows\FileHistory\Configuration、D:\FileHistory\User\D:\FileHistory\User\202108ACERPC\Configuration\Configuration Not destroyed But several days later, there is still no meaningful response. This is extremely frustrating. Microsoft cannot keep telling users to troubleshoot the same thing over and over again while providing no explanation of what is actually happening. If this is a Windows bug, Microsoft should acknowledge it. If it is not a Windows bug, Microsoft should explain what is causing it. What users should NOT get is silence. If other Windows 10/11 users are experiencing the same issue, please share your Windows version, KB number, when the problem started, and whether files are still being written to the FileHistory folder. The more users report the same behavior, the harder it will be to dismiss this as an isolated configuration problem. Microsoft, please stop leaving users to figure this out on their own. Investigate the problem, explain what is happening, and provide an actual fix. We need answers, not silence. The following are the problems that users and I encountered.
Decided to opt out of windows insider and now windows wont download the update
As the title says I decided to opt out of windows insider (26H2) and go back to the normal windows build. After using the opt out slider in the settings windows keeps trying to download version 25H2 and failing. I keep getting the notification about my windows build expiring on august 11th, which is mildly concerning since that is todays date and would rather not stop recieving all updates. I contacted support who took control of my pc and then told me they couldnt help me further as I was still on the windows insider build. I am unsure what to do now as windows is repeatedly telling me my build is expired, and trying to redownload the same thing over and over.
Secure Time Seeding / W32Time Large Time Correction Issue
Hello everyone, I’m investigating an unusual time synchronization issue with Windows 10 IoT Enterprise LTSC involving W32Time and Secure Time Seeding (STS) in a closed network, and I’d appreciate any guidance or insights from the community. In our environment, time.windows.com resolves to our internal IP/NTP server. The server receives NTP requests and returns a valid response with the correct time. Network monitoring confirms that both the request and response are working correctly. However, we observed an unusual behavior: If the system clock is set to 2035 or earlier, W32Time successfully corrects the time. If the system clock is set to a much later date, such as 2056, W32Time receives the correct NTP response but does not update the system clock. This behavior has been observed in both open and closed networks. We have already tried: Configuring MaxPosPhaseCorrection and MaxNegPhaseCorrection to 0xFFFFFFFF. Enabling UtilizeSslTimeData = 1. Unregistering/registering W32Time. Stopping/starting the Windows Time Service. Reconfiguring the NTP peer. Running w32tm /resync. Verifying NTP traffic and responses using network monitoring. We are also trying to understand how Secure Time Seeding (STS) works in this scenario. On an open network, STS appears to obtain and cache trusted time, which may help Windows recover time while offline. However, in our closed network, where time.windows.com resolves to our internal NTP server, STS does not appear to establish trusted time in the same way. Questions: Is there a W32Time or Secure Time Seeding limitation that prevents very large time corrections, even when MaxPosPhaseCorrection and MaxNegPhaseCorrection allow them? Why does synchronization work at 2035 or earlier but fail around 2056? Is the 2035/2056 behavior related to timestamp validation, NTP, STS, certificates, or another Windows limitation? Does STS require Microsoft's actual time infrastructure, or can an internal NTP server participate? Does resolving time.windows.com to an internal IP prevent STS from establishing a trusted timestamp? Is there a supported configuration on Windows 10 IoT Enterprise LTSC to treat an internal NTP server as a trusted time source? Are there specific W32Time event logs, registry settings, Group Policies, or diagnostics we should check when an NTP response is received but not applied? Accurate and trustworthy time is critical because timestamps are used for offline operations. Any guidance on whether this is caused by W32Time large-offset handling, Secure Time Seeding, timestamp validation, or an interaction between these components would be greatly appreciated.[SOLVED] Memory Integrity bounces back to "turned off" state after Windows restart - fast ring 19536
This is an old post and the issue is no longer relevant. This has been happening since a couple of builds ago as well. I turn on the Memory Integrity in Core isolation section of Windows Defender, then after a restart or two, I go check again and see it's turned off. it usually happens when I uninstall a program that needs to be restarted. but it also happens when I uninstall a software that does Not need Windows restart to finish uninstall process. https://aka.ms/AA6xajf
