Microsoft .NET - Check Failed (Vortex 1.6.7)

[exlandia]

Luckily I have a full backup of my system with an earlier version of Vortex on it. If this doesn't get fixed somehow soon, it'll mean hours of Fallout 4 game time lost.

[exlandia]

The problem for me has been resolved thanks to a Microsoft tech chat. I needed the VC_redist.x64

 

https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

[SylvanniRae]

The problem for me has been resolved thanks to a Microsoft tech chat. I needed the VC_redist.x64

 

https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

THANK YOU. You are a life saver. This fixed it for me, though I do not understand why. I thought I already had that installed.

Edited September 2, 2022 by SylvanniRae

[Tannin42]

Vortex installs the vc runtime as part of its setup if it's missing.

The only reason I can see that wouldn't happen is if you did, in fact, have the runtime installed but that installation was corrupted. Reinstalling the runtime then repairs it.

[exlandia]

Yes, it was already installed, but needed to be updated to the latest version.

[Platinumoxicity]

None of the fixes work on my end, except turning off sandboxing in Vortex. Repairing the .NET installs does nothing. Changing the permissions of Program Files does nothing. Installing VC_redist.x64 does nothing.

 

UPDATE: I realized that the only games affected are ones that are installed on the C: drive. Mods can be installed with no problems on non-system drives. Even though the game in question is not in Program Files or any other "protected" directory, Vortex can't be in sandbox mode and install mods to any game that's installed on C:.

Edited September 5, 2022 by Platinumoxicity

[Tannin42]

None of the fixes work on my end, except turning off sandboxing in Vortex. Repairing the .NET installs does nothing. Changing the permissions of Program Files does nothing. Installing VC_redist.x64 does nothing.

 

UPDATE: I realized that the only games affected are ones that are installed on the C: drive. Mods can be installed with no problems on non-system drives. Even though the game in question is not in Program Files or any other "protected" directory, Vortex can't be in sandbox mode and install mods to any game that's installed on C:.

 

To clarify: Technically the location of the game is only indirectly relevant, what matters is the application directory of Vortex itself and .NET and then the staging folder (settings->mods). If you're modding bethesda games or a few others you will definitively have set the staging folder to be on the same drive as the games though.

If you can successfully install mods for games with the staging folder on not-C then that rules out the application directories and it's indeed the staging folder that is the problem.

 

The necessary access rights for the Vortex app directory are given by its installer, the access rights for .NET are given by default on windows (unless user "mis"configured the system, see pinned message), the access rights for the staging folder are given by Vortex at runtime. That requires your windows account to own the staging folder but that will usually be the case because Vortex creates that folder for your account.

 

So the only way I can see that the pinned fixes wouldn't work but only on one drive but not the others is if the staging folder there isn't actually owned by your account. So either you have a second windows account (could also be something like a dedicated admin account) that created that folder or you moved that folder from a different windows install and didn't update the owner.

[Platinumoxicity]

 

None of the fixes work on my end, except turning off sandboxing in Vortex. Repairing the .NET installs does nothing. Changing the permissions of Program Files does nothing. Installing VC_redist.x64 does nothing.

 

UPDATE: I realized that the only games affected are ones that are installed on the C: drive. Mods can be installed with no problems on non-system drives. Even though the game in question is not in Program Files or any other "protected" directory, Vortex can't be in sandbox mode and install mods to any game that's installed on C:.

 

To clarify: Technically the location of the game is only indirectly relevant, what matters is the application directory of Vortex itself and .NET and then the staging folder (settings->mods). If you're modding bethesda games or a few others you will definitively have set the staging folder to be on the same drive as the games though.

If you can successfully install mods for games with the staging folder on not-C then that rules out the application directories and it's indeed the staging folder that is the problem.

 

The necessary access rights for the Vortex app directory are given by its installer, the access rights for .NET are given by default on windows (unless user "mis"configured the system, see pinned message), the access rights for the staging folder are given by Vortex at runtime. That requires your windows account to own the staging folder but that will usually be the case because Vortex creates that folder for your account.

 

So the only way I can see that the pinned fixes wouldn't work but only on one drive but not the others is if the staging folder there isn't actually owned by your account. So either you have a second windows account (could also be something like a dedicated admin account) that created that folder or you moved that folder from a different windows install and didn't update the owner.

 

So, what could the solution be if my staging folders are all in default locations in Appdata on C:, no mods can be managed for games installed on C:, and there are no issues managing mods for games installed on G:? I have two Windows accounts but I have never installed or used Vortex on the other one. The folder in Appdata is by definition owned by my main account. Also, "fundamentally misconfigured Windows" pretty much says nothing. I installed Windows 10 about seven months ago. Would upgrading from Windows 7 with official installation media to Windows 10 somehow cause some vague misconfiguration that can't be fixed without a clean install? -Because that is not something I am willing to do, especially since apparently no other application has any issues with sandboxing functionality. Only Vortex has issues.

 

UPDATE: Interesting property of this issue. When I'm managing a game installed on C:, I can turn off sandboxing and install mods just fine, right? Well. If I turn sandboxing on, I can actually continue to manage, to activate and deactivate mods that could not be initially installed while sandboxing was on. So, sandboxing prevents me from installing mods fresh on games on C:, but it does not prevent already installed mods on C: from being managed in Vortex.

Edited September 6, 2022 by Platinumoxicity

[zetim]

 

None of the fixes work on my end, except turning off sandboxing in Vortex. Repairing the .NET installs does nothing. Changing the permissions of Program Files does nothing. Installing VC_redist.x64 does nothing.

 

UPDATE: I realized that the only games affected are ones that are installed on the C: drive. Mods can be installed with no problems on non-system drives. Even though the game in question is not in Program Files or any other "protected" directory, Vortex can't be in sandbox mode and install mods to any game that's installed on C:.

 

To clarify: Technically the location of the game is only indirectly relevant, what matters is the application directory of Vortex itself and .NET and then the staging folder (settings->mods). If you're modding bethesda games or a few others you will definitively have set the staging folder to be on the same drive as the games though.

If you can successfully install mods for games with the staging folder on not-C then that rules out the application directories and it's indeed the staging folder that is the problem.

 

The necessary access rights for the Vortex app directory are given by its installer, the access rights for .NET are given by default on windows (unless user "mis"configured the system, see pinned message), the access rights for the staging folder are given by Vortex at runtime. That requires your windows account to own the staging folder but that will usually be the case because Vortex creates that folder for your account.

 

So the only way I can see that the pinned fixes wouldn't work but only on one drive but not the others is if the staging folder there isn't actually owned by your account. So either you have a second windows account (could also be something like a dedicated admin account) that created that folder or you moved that folder from a different windows install and didn't update the owner.

 

I think I'm in a similar boat. I upgraded from windows 7. I have vortex installed on my C: drive, but steam and most of my games are on a separate drive. I am definitely the owner of all the drives, unless the Windows 10 upgrade utility did some wonk. This setup was a little wonky on windows 7 with permissions, but I got it working. I updated to windows 10 and hadn't used vortex in a while. Tried to use it this week and started getting the .net error. Went through most of these fixes, but couldn't actually edit permissions in my C:/program files folder where vortex is installed, becuase it's greyed out (I'm assuming from inheretence? I'm not 100% on how windows 10 does stuff tbh), and it's also already there. I tried adding the ALL APPLICATION PACKAGES to the steam folder where my games are installed, and to the folder where the mods are stored on the same drive. None of this has worked. I still get the same error in Vortex.

 

I haven't tried reinstalling Vortex, or disabling sandbox, yet. I would rather reinstall Vortex, but I'm worried about losing the mod configuration on the reinstall. I assume it won't tear out mods from games on its way out, but I am worried that it won't know what mods are installed already and how to handle them for modification going forwards. I didn't see anything in a QA or FAQ about how Vortex handles mod configurations, whether it's tied into the program locally or stored in some sort of app data folder that will be retained even when uninstalled or something akin to that. I'm assuming most of this mess was caused by the windows 10 upgrade shuffling things around in a way that vortex was not designed to handle (and honestly that it still works at all after an OS change is something of a miracle), and a reinstall would potentially fix that. I've included my error and dotnet info here:

 

 

 

 

Asking OP/devs in general, can I safely uninstall and reinstall Vortex? Or will that break everything?

[ElabueloMora]

Gracias. Un vez que identifique el directorio correcto de dotnet (use el comendo dotnet --info), pude entonces usar ambos comandos de sugeridos en esta respuesta

En mi caso el directorio era "c:\Program Files (x86)\dotnet\shared" y el resto del comando. Dado que mi SO esta en español, tuve que revisar las opciones para poder llegar al directrorio correcto usando el comando del primer párrafo

Al final los comandos que use fueron estos:

icacls.exe "c:\Program Files (x86)\dotnet\shared" /grant "*S-1-15-2-1:(oi)(ci)(rx)"

icacls.exe "c:\Program Files (x86)\dotnet\shared" /grant "*S-1-15-2-2:(oi)(ci)(rx)"

Y entonces se solucionó el problema

---------------------------------------------------------------------------------------------------------------------------------------

 

Thanks. Once I identified the correct dotnet directory (use the dotnet --info command), I was then able to use both of the commands suggested in this answer.

In my case the directory was "c:\Program Files (x86)\dotnet\shared" and the rest of the command. Since my OS is in Spanish, I had to review the options to be able to get to the correct directory using the command in the first paragraph

In the end the commands I used were these:

icacls.exe "c:\Program Files (x86)\dotnet\shared" /grant "*S-1-15-2-1:(oi)(ci)(rx)"

icacls.exe "c:\Program Files (x86)\dotnet\shared" /grant "*S-1-15-2-2:(oi)(ci)(rx)"

And then the problem was solved