|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
Not sure where to post this: There’s a serious bug in Autoruns: If you open the Print Monitors tab and delete obsolete print monitors, all print monitors will be deleted. (Don’t try this withoug creating a Restore point.) According to a web search, this has been known about for a while.
GaryK
Autoruns has definitely not kept pace with Microsoft’s changes to Windows. For example, take a look at New startup registry key in Windows 10/11, NOT captured within autoruns
Good to know. But this particular bug bites Windows 7. It seems MS has orphaned the SysInternals tools. There’s a bug in Process Monitor too: Clicking on Column heads, which should trigger a sort, does nothing.
GaryK
Not sure where to post this: There’s a serious bug in Autoruns
If you mean the current Autoruns 14.11 then I count several serious bugs reported since last June. In addition to your print monitor issue I also found:
I note that Autoruns 14.11 is itself an update to Autoruns 14.10 to fix a bug parsing parameters in startup folder items.
(14.10 was a bugfix to 14.09… which was a bugfix to 14.08… and so on and so on. According to this changelog the last release that wasn’t a bugfix appears to be back in Sept. 2021.)
@gkarasik, from my notes dug out earlier, autoruns v13.1 was the LAST ‘official’ version for WinXP, Vista AND Windows 7.
Subsequent versions were intended for Windows 8, 10 and 11..
Edit to add a later found link
Ref: https://portableapps.com/apps/utilities/autoruns-portable
Version Note: The legacy 13.100 version is used on Windows XP/Vista/7 as it is *the last version to support those operating systems.
* my bolding for emphasis
no issues here on Windows 7 Pro, note autoruns version 😉
Hmm… I may possibly have found another bug in Autoruns…
If you start Autoruns using Run as administrator you’ll see two locations for Run registry subkeys (at the top of the Everything tab) – one for the current user (HKCU) and one that’s system wide, i.e. for the machine (HKLM):
All well and good… so far.
However, I used PowerShell to carry out a WMI query of the Win32_StartupCommand class:
Get-CimInstance -ClassName Win32_StartupCommand | Select-Object -Property Command, Description, User, Location | Out-GridView
The objects returned show several more Run locations (b and c) in addition to those shown by Autoruns (a):
Curiouser and curiouser… (especially as I thought I had ripped out OneDrive by force after uninstalling it in Admin mode during OOBE). I assume it’s because we’re not supposed to see what services are doing in the background… even if we run Autoruns elevated.
PS – Why is Google’s Drive File Stream being run by the System account as well as by 2 services? Overkill, much?
It also suggested that me disabling Google’s Drive File Stream in the HKCU Run key (as the Autoruns screenshot shows) may have been completely ineffectual. However, I’ve just checked using System Informer and it’s not running in the background… so I don’t know what the ‘–startup_mode’ switch actually does.
(And… isn’t it rather presumptious for Google to write to what is effectively the ‘new user’ template (c)? What if I don’t want any newly-created user account to run Google’s Drive File Stream in the background?)
Hope this helps…
Autoruns displays startup entries for individual accounts. In the main menu click “Users”. You should see a dropdown menu of all the accounts that can be examined, including the service accounts. Perhaps that accounts for the apparent discrepancy between Autoruns and the WMI query.
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
