-
-
I would expect Outlook to put up some sort of “.pst error” message upon opening Outlook or attempting to read an email msg previously downloaded and already contained within your .pst file but I really don’t know as (to my knowledge) I don’t think I’ve ever had a corrupted .pst file.
One last thing I can think of is maybe your “Server Timeouts” slider setting on Outlook’s advanced settings tab is set too short in your system’s environment (Outlook/Windows version, ISP internet connectivity/bandwidth, etc) so Outlook isn’t allowing enough time for Gmail (Google) to respond to the login request & timing out then assumes wrong credentials were sent so asks for your login credentials again.
Though in my environment, Outlook 2013’s default of 1 minute seems to be adequate, Gmail (Google) recommends a Server Timeouts setting of:
Greater than 1 minute (5 is recommended)
Try moving the slider towards the middle or even all the way to the right to see if this resolves the intermittent login failures.
If you still want to set your mind at ease & perform a .pst scan, Microsoft instructions can be found here, here & here.
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
-
Yep, been there done that, every now & then same thing happens here when poking around the internet on the PC/laptop or face timing on the iPhone/iPad.
In the past, I used to spend 15-20 minutes trying to determine if it’s the PC/laptop, iPhone/iPad, GCI cable modem, my router or ISP and found that both the GCI modem or my router has a tendency to loose internet connectivity usually after several months of normal operation.
So in my case, I connected both my GCI modem & personal router to a separate power strip so I could simply simulate a utility “power loss” (we often have these living in Alaska especially during this time of year) by switching the power strip momentarily OFF (10-15 sec) then ON again which simultaneously reboots both and so far this has resolved the issue every time.
My question for Susan is … why did it seem to only effect your access to AskWoody while other sites came up OK?
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS -
If your Google “insecure apps” setting is “enabled” & you’re still having problems sending emails, verify your gmail POP & SMTP server port settings are set correctly in Outlook per “gmail” instructions posted here.
For secure transmission, use port 995 for POP, 587 for SMTP with encryption type TLS (or Auto).
Microsoft still suggests using the “implicit” TLS port 465 in Outlook settings for gmail here but gmail port 465 now only works (recent change?) with encryption type set to SSL, not TLS or Auto.
Additional info describing differences between SMTP ports 465 & 587 can be found here.
My working Outlook 2013 gmail POP3 account setting’s are:
Good luck
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS -
Apparently this final collapse & potential decommissioning were previously anticipated after an auxiliary support cable detached in Aug 2020 followed up by another main cable break on Nov 6th.
An auxiliary cable came loose from a socket on one of the towers in August, creating a 100-foot gash in the dish. Engineers were assessing and working on a plan to repair the damage when another main cable on the tower broke on November 6.
The entire CNN news article about planned decommissioning can be found here.
NSF.Gov news release 20-010 about the decommissioning plan can be found here.
Wonder if the drone being in the exact right place at the exact right time to capture the remaining main cable breakage was part of the decommissioning plan … hum
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS -
@Cybertooth … that’s AWESOME & what a GREAT find
Those darn 3rd party Anti-Virus/Malware products – now I know why Woody always recommended not using them.
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS2 users thanked author for this post.
-
Well, I’m now completely stumped … this IS a very interesting & challenging problem.
SFC should have found/fixed any Windows OS file issues which I would expect to include the cmd.exe, consent.exe & appinfo.dll files.
Safe mode ran fine so cmd.exe file is probably OK.
UAC nor McAfee runs in safe mode so if SFC did check consent.exe & appinfo.dll and found no errors, I would suspect some other 3rd party program that interfaces with UAC the culprit with McAfee being the most likely.
By the way, both consent.exe & appinfo.dll files are periodically updated by MS and if you search for either of these, you’ll find several versions of them in your Windows Winsxs folder under several subfolders with names starting with:
“amd64_microsoft-windows-lua_31bf3856ad364e35_{version# & ID here}”
My consent.exe version is 6.1.7601.24561 which I got when I installed the Oct 2020 updates on 10/24/2020.
It could still be a user profile problem which may be worth a try but assuming you logged into safe mode with same user profile, I wouldn’t give this much hope.
I guess it could also be some “other” non-Windows program but this is only a guess.
As you’ve installed ESU updates using @abbodi86’s script, I’m not sure you can easily “uninstall” them like you would normally – something about first having to somehow re-install the last pre-ESU Rollup then backing out the latest ESU Rollup. You’ll need to scroll through the ESU script topic for more info.
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
Thanks but … I believe your link applies to Windows 10 version 2004.
Google does consider MS Outlook (especially older versions like 2013 & earlier) to be an “insecure app” and periodically they disable the insecure apps setting without any advance notice or your permission (unless it’s already there in their ULA).
This happens to us every couple of months or so running Win7 & Win8.1 and our first indication that Google turned it OFF is Outlook starts asking for our password(s) again & Outlook still fails to log into our gmail accounts even if we do enter in the password(s).
As with everything else Google, they seem to know what we want before we want it even though we really don’t want it
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS -
In safe mode, McAfee shouldn’t have been running & your admin CMD.exe worked so I still suspect your Anti-Virus is somehow erroneously interfering with the normal operation of Windows UAC which consists mainly of the Windows Application Information Service (Appinfo) & the Consent.exe program.
All of these 3rd party Anti-Virus products DO hook into UAC (as designed by MS) to primarily ID themselves/processes as “trusted processes” so that the user isn’t constantly bombarded by UAC permission prompts whenever they’re performing their anti-virus & malware protection tasks.
A good primer on UAC can be found here. Figure 4 shows a good overview of how UAC works.
As your McAfee version is not exactly what’s specifically address in McAfee’s Knowledge Center article, I’d be a little leery trying their proposed workaround – it may work but then again it may also screw things up more.
I’d first poke around your McAfee product’s settings to see if something can be turned either OFF or ON that fixes the problem.
If this doesn’t work, I’d consider uninstalling McAfee, reboot & another SFC /scannow to verify McAfee uninstall didn’t break anything, verify that administrator’s CMD.exe now works, then (as desired) a fresh reinstall of your McAfee S/W (up to date version if possible). Re-verify all is well – if not, you now know exactly what the problem is.
Good luck
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
As you mentioned running McAfee in one of your earlier posts above, look what’s addressed on the McAfee Knowledge Center website dated 6/23/2020.
Might this be the cause of the odd administrative privilege elevation issues you’re having
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
@Morty …
To find all November 2020 Windows updates in the Microsoft Update Catalog, search for “2020-11” (no quotes). You’ll have to scroll thru several pages and pick only the ones applicable to your Windows version & bitness (x86 or x64).
For Windows & MSOffice updates, you can still get November’s via Windows Update (WU) up to & even after MS has released the December updates.
First run WU. After WU finds all outstanding updates, highlight (click on) each found update and verify that it’s release date (in description area on left) is prior to Dec 2020. If any are dated Dec 2020 (or later), first uncheck then hide these updates.
Once all updates dated Dec 2020 (or later) have been hidden, run WU again. This time WU will find & display the outstanding November 2020 (or prior) updates that were superseded by the hidden Dec 2020 updates.
After all your Nov 2020 (or prior) updates are successfully installed and system’s been rebooted, if you hid any Dec 2020 updates, run WU again and restore these hidden Dec 2020 updates so they can be found again when it’s time to install these later on (when we’re out of MS-DEFCON 2 for the Dec 2020 updates). You can safely exit out of WU without installing any of the re-found Dec 2020 updates.
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
Apparently, the “right” buttons are being pushed
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
Grasping at straws here but can you create a new user account (admin preferred) then try running cmd.exe as admin after new user login? If this works, your current user profile may be corrupted which can cause all sorts of odd & unexpected problems.
You could also try running cmd.exe as admin after booting into safe mode – this would surely add additional info to this challenging but interesting troubleshooting exercise
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
-
When “cmd.exe” (the child process) is executed by the “elevated administrator task manager” (the parent process), cmd.exe (child) acquires its elevated administrator’s privileges from the elevated administrative task manager (parent) and runs as “admin” as expected.
When a user tries to execute an elevated command/script/program (child process) from the console (a parent process without admin privileges) regardless of whether or not the user is an administrator & dependent upon the system’s User Account Control (UAC) settings, UAC calls “consent.exe” (Consent User Interface for Administrative Applications) to ask for permission and/or administrator’s password to execute the command/script/program under elevated administrative privileges.
It sounds like the “consent.exe” file in Windows System32 may be missing or corrupt.
It’s been known in the past that Avast & AVG (maybe others?) mistakenly flagged the “consent.exe” file in the Windows System32 folder a virus and deleted it from the System32 folder. If so, it may have been moved to the Anti-Virus’s protected quarantine for possible future restoration and may still be there.
Other 3rd party Anti-Virus products/updates (Symantec Endpoint Protection was one) may also have injected their DLL(s) into consent.exe which may have corrupted it.
If “consent.exe” is either missing from the Windows System32 folder or it’s corrupted, as @glnz indicated above, “SFC /scannow” should resolve this issue.
Hope this helps
@glnz … what a sneaky backdoor into administrative command prompt(edit – typo)
Win7 - PRO & Ultimate, x64 & x86
Win8.1 - PRO, x64 & x86
Groups A, B & ABS1 user thanked author for this post.
Author
