0_x64__8wekyb3d8bbwe

[Jan Dominquez]

Metroapps in windows seem to have a special extension to their installation directory, for example the new Windows Terminal is located at C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.3.2382.0_x64__8wekyb3d8bbwe\. I've noticed that other metro apps also have that _8wekyb3d8bbwe extension in their path.

It looks similar to the installation directory path but there is no version or architecture in the command (the _1.3.2382.0_x64_ part is missing). However I have to specify _8wekyb3d8bbwe to get it working and I'm curious what this is.

As to why this string was chosen and no other, I have no explanation.Maybe some Microsoft developer just randomly hit his keyboard.From the distribution of the letters, he might have used his left handto do that.

You can see a list of all of your installed packages by running Get-AppxPackage * in PowerShell. In the list, you can see that most apps are by Microsoft, and will have Package IDs ending in 8wekyb3d8bbwe. You also might be able to find some released by other companies, with other Publisher IDs.

I find out how to have access to WindowsApps directory, and I can copy a file inside WindowsApps directory, but not insided \Microsoft.FlightSimulator_1.18.15.0_x64__8wekyb3d8bbwe

When I try to copy a file inside this folder I get a message saying that there is not enough space in the folder (and that is absurd, the file is small and I have lots of Gb on my hard drive, so must be some type of protection).

I also share the opinion that MY COMPUTER is mine, and nobody (Microsoft in this case) should forbid me to access and copy anywhere if I need, specially when we talk about a game, and there is no restriction to do the smae using Steam.

I have been having an ongoing problem (for months now, even back on version 9.xx) with firewall rule creation involving only one specific file, HxTsr.exe (Microsoft Outlook Communications). I've created probably close to 50 rules to allow this file outbound access to the various email websites run my Microsoft (office365.com. hotmail.com. outlook.com, etc.) but a few days later it's popping up again asking for permission to allow outbound traffic.

I've determined that the problem lies with the files' path. It seems that the file gets updated very frequently, and each time it gets updated, it's path changes relative to it's current version number. For example, the current path to the file as I write this is: C:\Program Files\WindowsApps\microsoft.windowscommunicationsapps_17.8400.41195.0_x64__8wekyb3d8bbwe\HxTsr.exe

I need a solution to this dilemma so that I am not constantly nagged every couple days to re-create firewall rules for this file, and then having to remember to go back into the rules and delete all the old ones that are no longer valid. Is there a way to create a rule for a specific file name, no matter what it's relative path may be, or perhaps a way to just ignore the file name all together?

Wildcards are not supported in firewall rules. Otherwise one could create a rule for svchost.exe for instance but since this is also a typical file name used by malware the rule would also be applied to both malicious and innocuous svchost.exe.

Below is a screen shot from Process Explorer. Note that I do not use any of the Apps the OP listed. However, I do use IE11 that does use an Outlook add-in. What is shown is that an "internal" Win firewall rule was created for instance of HxTsr.exe that BTW is a rule to allow communication from user's IE11 cache directory:

Next is a screen shot of the outbound Windows Firewall rules that were created by IE11 to allow communication for Outlook . Again note that the rules specify outbound communication from the user IE11 cache directory.

Bottom line - appears Win 10 creates firewall rules for Outlook for each application for which can employ it. Duplication of same rules are virtually next to impossible in conventional third party firewall rules; if for no other reason than they are SID dependent. Therefore it is recommended not to monitor Win 10 outbound connections in the Eset firewall.

While I completely understand the reasoning behind the inability to do this, there has got to be something that can be done about problem files like this. Can outbound traffic filtering be turned off and only filter inbound? Ideally I'd prefer keep both inbound and outbound, but the nagging has really started to rub me the wrong way. I'd really prefer not change the mode from interactive either.

Go into the Eset GUI -> Advanced setup -> Personal Firewall -> Advanced -> filtering mode and change to "Automatic mode." Then delete all the outbound rules you created. You can also reset the Personal Firewall settings to default which will recreate the default inbound and outbound Eset firewall rules and settings.

Call me strange, but I like the interaction of knowing when new things want to reach out, so Automatic is not desirable setting for me. I'm going to try one last ditch effort to create broad rules, when prompted by the pop ups, to just allow access out to the specific email server IPs on the requested ports for ANY application. This is really not what I wanted to do, as it leaves the door open for anything to reach out to those email servers, but if it stops the annoyance, I guess I will have to live with it.

You can do this in "Automatic" mode, by first creating an outbound rule allow rule for e-mail client app to e-mail server IP's. Then create a second outbound firewall to block any outbound traffic from the e-mail client app. Just make sure the block rule is below the allow rule. Eset firewall rules are parsed from top to bottom.

Like I said before though, it's not the actual email client (which happens to be Outlook 2013) that is the problem, it's the other file from Microsoft (HxTsr.exe) that is causing all the havoc. Creating rules for this specific file is fruitless as the file path constantly changes, based on the file version, which seems to be updated every few days. Any rule created for the file is made worthless every time the path to it changes, hence my original request.

The file also doesn't look for access to the email servers on typical email ports, it only goes out on remote ports 80 and 443. It most commonly connects to outlook.office365.com, but occasionally to autodiscover.hotmail.com, and one other that slips my mind right now. Not sure what it's looking for or doing on those servers, but it's not retrieving email, that's for sure.

3a8082e126