Goto Program Files -> find IE folder -> left click -> remove. it may do the job. tried now in my LTSC version, move the whole directory to Desktop. and system still work. yet. ( I want to test in in VM before .. )
Thanks "Dark Dinosaur": , I tried everything after making a big <mess> with my crazy/stupid script substituting etc.... > there are IE items in windows 11 @ all over the palaces eg....|%User\App\Local, |%....\localLow....to %\ProgramFiles....etc etc... >> even tried to <<TAKE OWNERSHIP> of all the "directories" where I found IE or INTERNET EXPLORER... >>> than do a DELETE ALL...... >>>> it created even bigger mess <grrr>> >>>>>it seems IE is still 'linked to Edge' and few other features in Win folder etc...((but than I am just a silly goof.. not know anything ..... Thanks for your suggestion(s) Thus my solution = was GOBACK = recover to previous last good install (funny enough ,this time,that GOBACK feature in windows11 worked nicely for me ...Phew! err... now I am forced to live with that 'do nothing' extra datafile crap; yet another thing that "bugs" me in Win11.Entp.x64 - but it seems to be a bit better than my last venture with Win-Vista !
Found a bug in the code. These lines don't work correctly: for /f "tokens=2*" %%V in ('reg query "HKCR\MSEdgeMHT\shell\open\command" /ve 2^>nul') do set "ProgID=%%W" for %%W in (%ProgID%) do if not defined MSE set "MSE=%%~W"& set "MSEPath=%%~dpW" Replaced it with one of these and it worked properly!: for /f tokens^=2^ delims^=^" %%W in ('reg query "HKCR\MSEdgeMHT\shell\open\command" /ve 2^>nul') do if not defined MSE set "MSE=%%~W"& set "MSEPath=%%~dpW" I wanted to ask, since I don't really understand vbs. Why or in what case does vbs use a hard link from msedge.exe to chredge.exe?
I agree, ideally then fix just one line instead: for /f "tokens=2*" %%V in ('reg query "HKCR\MSEdgeMHT\shell\open\command" /ve 2^>nul') do set "ProgID=%%W" Replace with: for /f "tokens=3*" %%V in ('reg query "HKCR\MSEdgeMHT\shell\open\command" /ve 2^>nul') do set "ProgID=%%W" "tokens=2*" to "tokens=3*" Why or in what case does vbs use a hard link from msedge.exe to chredge.exe?
You can't just drop that on me without mentioning the path you had. Maybe it's an issue with your configuration only. Either way, it's relevant, please provide before and after example. I've made it for standard configuration, where ProgID is something like "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --single-argument %1 where the second loop only takes the first part i.e. MSE is something like C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe Your replacement should give literally the same output, except it's no longer fitting the self-imposed 130chars per line. And this is not used by the vbs. This is used in the batch install part to detect edge installation and create the hard-link if found (a one-time operation). The vbs just blindly replaces msedge with chredge in the command-line in the off-chance the redirection should not proceed (missing protocol) - so that normal edge can still be used. The point is to allow manually starting edge if already installed, and only redirect those pesky links. But once already redirected, you can't start edge anymore, so that's where chredge hard-link comes in: it circumvents IFEO shortcomings in a simple way, self-reflect back to edge sort-of-speak, while keeping edge update & etc working. When edge is not detected, it's simpler, as you just have to replace registry entries originally pointing to edge, to bho, and then redirect that.
I don't know the EN language very well, so I don't write in a very clear way. I found out the cause of the problem. The problem turned out to be the output of the "reg query" on my localization. The complete output should have looked like yours on EN: (Default) REG_SZ "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --single-argument %1 But with a different encoding "(Default)" is output as 2 words, or may be output as 3 or 4, depending on the language. Therefore, the filter "tokens=2*" works differently. But if you change the encoding to UTF-8: chcp 65001 >nul, the output is "(Default)" as in EN. And then "tokens=2*" filters correctly, as intended! Replaced this one line in the script: @echo off & title ChrEdgeFkOff || AveYo 2022.05.22 on this: @echo off & chcp 65001 >nul & title ChrEdgeFkOff || AveYo 2022.05.22 And it all worked out the way it was supposed to. I tested it on W11 22000.778 x64 Regarding the hard link to chredge.exe, I understand that it is done once, I was wondering in what case it is used. Now I understand, thank you. Then why block msedge.exe via IFEO so that it can then be run via a shortcut with a redirect to a hard link? My point is that the "pesky links" are redirected to the default browser via a protocol "microsoft-edge:": UWP -> "microsoft-edge:...http://" -> \Classes\microsoft-edge\....\ -> ie_to_edge_stub.exe -> IFEO -> vbs start "http://...." -> Default Browser Then why block msedge.exe itself from running through the shortcut or its exe? In this case, the \Classes\microsoft-edge\ protocol is not used: msedge.exe -> IFEO -> vbs start "chredge.exe ..." p.s. I use chcp 65001 >nul in all my scripts and always temporarily change it to OEM for output from utilities when necessary to avoid scribbles in the output.
@westyles, you forgot the context: - microsoft blocked all workarounds, multiple times so far - and they keep doing lame stuff like using shell infrastructure server to directly call edge, bypassing and escaping IFEO! - I'm the first making these up-to-date key workarounds (and I do encourage others to implement them in their alternatives, for example https://github.com/rcmaehl/MSEdgeRedirect and https://github.com/HarshalKudale/NoMoreEdge) Everything has a reason. There has to be a chain of workarounds accommodating most scenarios with edge removed or not. I have to tackle the nasty IFEO escape, the inherent IFEO restrictions, the command being ignored without edge signature, the edge update failing and etc. while doing all this in the most av-friendly way (if you check old revisions, there was stuff dealing with ifeo better, but tripping av behavior monitoring) Be my guest experimenting yourself, I welcome improvements. p.s. you want to know more about the thought process behind a mere 90 lines plain text script, but when asked about the particular scenario failing you're not as fore-coming. that's ok, I'll install 10-15 localized windows and find out which need adjustments, I simply forgot about this reg query peculiarity
Me too. For other reasons. PS output font changes .. My default script start Code: @cls @echo off >nul chcp 437 setlocal enabledelayedexpansion title ...
It's hard for me to understand you, so I detailed the point as best I could. I thought it wasn't necessary to demonstrate by example. Test_check.bat: https://drive.google.com/file/d/18YsKw0-GzvUJCmS6d71Bc9DJm4PU0YIb/view?usp=sharing screen run bat: https://i.imgur.com/U2XWYvA.png
pff, I've been asking for the localization name / codepage so that I can reproduce it in a real environment, nothing more. thank you
I wanted to make it easy for you and show you the essence of the problem. And you can test the behavior on different output variants on EN localization, as shown in the bat file. My localization is RU, the default encoding: cp866 I saw your cool script 2 days ago, and when I checked it, the path to msedge.exe was not created in IFEO, and the *stub.exe file was not copied. I manually copied the file and everything started working, including running msedge.exe (because there was no path in IFEO). Copying the file and creating the path is tied to this localization problem. When I corrected the script, the file began to copy itself, and the path in the IFEO is created, and the launch of msedge.exe became through chredge.exe. But that's why I asked - why block msedge.exe, since in both cases, the behavior is essentially the same, with and without blocking. And I assumed that means there is some condition that needs this blocking and redirecting through chredge.exe. And I asked about it, but I still haven't figured out what condition it is to check. Perhaps you meant that msedge.exe can run from UWP not through a protocol but by running Edge itself with parameters. But so far I haven't found any such behavior. No offense, but your writing is very convoluted, and it's hard for me to understand your point from the translation Your scripts have been known to me for a long time; there are very few professionals like you, especially those in the public sphere. You help a lot of people, so I couldn't help but write to you about the problem I identified. This can easily happen, because the behavior on different localizations can not always be predicted beforehand.
Don't worry about it, it's just miscommunication. Example: Settings - Windows Update - Windows Insider Program - Becoming a Windows Insider link Should be redirected, but it's not, because it escapes IFEO via sihost. Without the extra steps, it would just error out with a fullscreen blank window when edge is installed (under 11). So not launching is better than that (bho acts as a noop). Under 10 the workarounds are better.
Forgot about this issue, sorry. Should be fixed now. I also modified my helper reg_query / reg_var snippet accordingly: Code: :reg_var [USAGE] call :reg_var "HKCU\Volatile Environment" value-or-"" variable [extra options] set {var}=& set {reg}=reg query "%~1" /v %2 /z /se "," /f /e& if %2=="" set {reg}=reg query "%~1" /ve /z /se "," /f /e for /f "skip=2 tokens=* delims=" %%V in ('%{reg}% %4 %5 %6 %7 %8 %9 2^>nul') do if not defined {var} set "{var}=%%V" if not defined {var} (set {reg}=& set "%~3="& exit /b) else if %2=="" set "{var}=%{var}:*) =%"& rem AveYo: v3 if not defined {var} (set {reg}=& set "%~3="& exit /b) else set {reg}=& set "%~3=%{var}:*) =%"& set {var}=& exit /b So in this case, it would be used like this: call :reg_var "HKCR\MSEdgeMHT\shell\open\command" "" ProgID Or to get a value like SteamPath: call :reg_var "HKCU\Software\Valve\Steam" "SteamPath" steam_path Returns nothing if value not found (so you can test with if defined). And should work regardless of codepage (but I haven't tested it). Edit: 3rd time, the charmer
In general everything works, great and tricky method! There is one drawback, if the parameter (default) is not set, it outputs the name in brackets: (parameter value is not set) echo. ProgID: "%ProgID%" >>>> ProgID: "(значение параметра не задано)"
@AveYo I keep getting this error on a MS Surface pro 4 running Windows 11 on which I used Edge_Removal.bat to remove Edge. Could this error be related to removing Edge? I removed Edge using your script on a laptop running Windows 10 LTSC 21 and I don't get the error.
@JBenal Haven't seen such thing in various windows 11 versions, but then again I don't use much store stuff. Without useful info, I can only recommend reinstalling webview2 manually. A dumb 3rd party program / app you have might do this (microsoft stuff acknowledge it missing and do not throw such garbage). Use a competent task manager to identify where is the error coming from (process explorer - run it as admin, menu View - Show processes from all users; click sniper-scope icon and drag it over the dialog).
I followed the directions on this site, then ran sfc /scannow https://www.800error.com/error-code-0x8007000B-Windows-Update-Microsoft-Fehler-unter I'll reboot the computer and see if the error returns. Thanks.