rseiler

Was anyone shunted to a Windows setup screen about continuing to use facial and fingerprint recognition (neither of which I use) when upgrading to the .15 release? I've never seen that screen before, so it was a surprise. I chose one, since there seemed to be no other choice, clicked Next, and it then opened Settings, Accounts, Sign-in options. 23570

Nice, thanks. I was getting a little worried by what happened in Canary given that I'm on Dev and therefore on any given week some or all of the relevant changes from Canary could have migrated over without warning, musical-chairs style.

Is that in Dev? At least there, I haven't seen Copilot at all, perhaps because I have it disabled in group policy (User Config, Admin Templates, Windows Components). There would also be an equivalent Registry mod to do the same for those without gpedit.

There's a very, very long history of patching termsrv.dll successfully. If done right, the only thing the OS does is replace it on the next Patch Tuesday (assuming that's one of the files updated that month).

Suggestion: Upon installing a new Windows build, SaB triggers a notification telling us that there is no new version (of SaB). It would probably be better to only trigger that if there is. since otherwise it's a notification of nothing, which isn't normal.

I'm on that build. While I don't have any desktop items to right-click, note that a workaround for the CP issue would have been to access it in Start via the Menu display option, as that worked. As did accessing it via a right-click on Start (if you have that configured, which is not a feature of SaB). It probably would have run via Start/Run/control.exe, too, though I'm not sure about that one.

Is that a more severe version of the problems that began with 25921 early in the month?

I assume you mean Canary. Check p.98 of the main thread for news on that.

@AstragonQC I can't really tell the import of what Xeno is showing in that screenshot, but is SaB at the mercy of MS not removing things they're barely (or not at all) even using anymore? If so, we're in trouble. Did you try 3.6.11? I'm on 23xxx so can't test 25xxx.

23516: No problem (with the test build), so we're definitely back to normal.

23511 looks to be presenting a problem for 3.6.10, at least if you use a vertical orientation for the taskbar. If you do, the taskbar is entirely blank except for Start itself.

Unsure if it's a 23xxx problem or the SAB test build (using the one with the July 9 signature), but selecting "Pin to Start Menu" for an item in the Start Menu actually pins it to the taskbar instead, as if you chose "Pin to taskbar."

@karazz Are you speaking of the OP issue (corrected by the test build) or the bizarro one that I mentioned, which may be related?

Have any of you on 23493 noticed a parallel Explorer issue? I saw it before the test build, too, but never before 23493. File Explorer itself gets into a funk where when you try to launch it, after about a second, it closes. But then if you try it some hours later, it may work! Or not. It's very strange. I'm using XYPlorer for now. The crash dump info is different than the shell one, which was BEX64 rather than APPCRASH: Description Faulting Application Path: C:\Windows\explorer.exe Problem signature Problem Event Name: APPCRASH Application Name: explorer.exe Application Version: 10.0.23493.1000 Application Timestamp: df7f3ef2 Fault Module Name: FileExplorerExtensions.dll Fault Module Version: 723.16708.0.0 Fault Module Timestamp: 648cf049 Exception Code: c0000005 Exception Offset: 000000000007e219 OS Version: 10.0.23493.2.0.0.256.4 Locale ID: 1033 Additional Information 1: 17e2 Additional Information 2: 17e2b7babec54ed5afc192f5a9f7f471 Additional Information 3: b805 Additional Information 4: b80543948f63128ad105915805d332b7

Yes, I'm past the period now and it hasn't recurred, so this seems good.

Will try it (who knew there was a separate thread on this), but I won't know for close to 24 hours if it worked or not because I just did today's workaround about an hour ago.

Just in case it means something, I offer up this ambiguous information concerning 23493, the first build to have CoPilot, a major change. For the record, I'm on SaB 3.6.8. I had been running 23493 continuously and without incident for almost 22 hours when I happened over to Taskbar Settings and noticed CoPilot toggled On. Since I'm using SaB, there was no obvious presence of CoPilot, and I didn't want it anyway, so I toggled it Off without a second thought. Within an hour or so, I noticed that the shell restarted, which was odd because I can't recall the last time that happened. Then it proceeded to happen basically every minute: They look like this: Example dmp: https://www.upload.ee/files/15396774/explorer.exe.5796.7z.html After the first couple of those, I rebooted but it didn't help. Then I closed everything I had been running (even though they were the same things I'd been running the last day), but no difference. Then I thought about the CoPilot toggle, so I put that back On, but no difference, even after reboot. So now I tried disabling SaB and it stopped happening, which was interesting, since why wasn't SaB a problem the first 22 hours? The only thing I can think of is some kind of strange (and delayed) CoPilot interaction, but I can't prove it. Not thinking that it would work, I re-enabled SaB, and after that reboot...there's again no problem. I don't really know what to make of this, but I'm going to go ahead and recommend not touching the toggle. Update: The above-mentioned rapid-fire shell crashes seem to trigger roughly every 24 hours, which I think explains why I didn't see it happen until around that amount of time in the first place, and why it went back into that mode a day after what I wrote above. It's perhaps objecting somehow to the presence of SaB at that interval, but if you play around with the toggle and temporarily switching SaB off, you can get back to a stable state (with SaB), though I'm pretty sure just for a day, when it all repeats. Update 2: In today's iteration I did this, which I think is the essence of the workaround, since don't forget that the problem starts because Windows can't do something that it needs to do: -Restarted the shell myself and used the ESC method to prevent SaB from loading. -Waited a couple minutes for Windows to do whatever it needs to do. -Restarted the shell so that SaB loads

@Manoes Wow, so you figured out that reverting to a build from 7 April 2022 (!) stops that window position problem from being one? Not sure how you did that, but I guess that's one way of showing SaB's involvement. I can't remember when the problem started, exactly, but a year ago is reasonable, though if you said two years ago, I might think that reasonable too. It's been too long either way.

@Manoes It's not just Explorer. It's most programs that I use, though much more position than size. Is that related to SaB though? If so, I didn't realize that, but I also haven't tested without it. Using this makes it less of a hassle: https://github.com/caoyue/WindowResizer I wish we had something similar for the tray icons all being hidden with each build upgrade. I've been experimenting with backing up and restoring these two areas, but no joy so far. I have no idea if it's even valid to do this between builds: HKCU\Control Panel\NotifyIconSettings HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify On the good news front, SaB 3.6.4 has an unannounced feature: it doesn't throw a build warning (i.e. disabling itself and making you re-enable) for 23xxx anymore.

Is the same mechanism used for the build compatibility check, which results in SaB being disabled, the boot halted, and then the user being required to answer a question about whether they really want to run SaB? If so, then "can't" would answer that question, too. If not, the question of whether there's a way to prevent the above remains.

Is there a way to suppress the Windows build check? Because if there is, perhaps via the Registry, it would be nice if that was revealed.

I'm not sure what 9/10 means, but yes, I'm talking about the SaB dialog that comes up very early after a new build install warning you about running it and essentially requiring you to opt-in if you want to run it. If that was meant to happen, it should have happened when going from 23403 to 23419, too. It definitely did not then, and that was just a week ago.

Though come to think of it, it didn't happen for earlier 23xxx, as I'd never seen this before, which makes me wonder which behavior is intended. Also, the timing of it, which was pretty early in the boot, may have contributed to the fact that the keyboard didn't work until after another reboot. Might have been a fluke, but I'd never seen that before either.

Is it expected that SaB 3.6.3 should display a compatibility opt-in warning message after a build upgrade to 23xxx (seen with 23424)? If so, is there a way to make it just opt-in by default and not ask? It's probably warranted for 25xxx but arguably not 23xxx.

Yeah, it looks like taming PastIconsStream and IconStreams, at the very least. Probably iffy.