I am trying to compile my program in visual studio and I am getting a FIPS Cryptographic algorithms error. I have checked the registry key and it is set to false.
Any suggestions?
I had a hard time with this too. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa. Under a subkey you should see FipsAlgorithmPolicy. DELETE this registry entry and restart visual studio.
REF: https://blogs.iis.net/webtopics/parser-error-message-this-implementation-is-not-part-of-the-windows-platform-fips-validated-cryptographic-algorithms-when-net-page-has-debug-true
You can fix this by adding <enforceFIPSPolicy enabled="false"/> under the runtime section in the .config files of:
MSBuild (example path: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe.config)
Visual Studio (example path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config)
My answer was to change the registry key from 1 to 0 here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy
Question is a bit general. My more specific error:
AppContainer Creation Failed with error message NONE, state This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms
Microsoft explains and lists a workaround here:
https://support.microsoft.com/en-us/help/911722/you-may-receive-an-error-message-when-you-access-asp-net-web-pages-tha
Open Web.config
Locate the system.web section
Add the key:
*<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>*
Save Web.Config, then iisreset from the command prompt.
Assumption is that company policy has set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\fipsalgorithmpolicy with a value of 1 (and of course, that IIS is running)
Would be nice to know why this effects the installation of Python and R on Windows SQL Server 2019.
Related
Visual Studio 2012, VS 2012 Command Prompt, VS 2010 Command Prompt, and a C++ console application compiled in 64-bit with VS 2012 are all reading an out of date instance of various registry keys. Each application (i.e. VS 2012, the command prompts, and the compiled app) all seem to have their own version of this out of date registry. Below are the symptoms I'm seeing and my various attempts to fix it.
I've both added new registry entries and updated the data in existing ones and all appear updated in HKLM\Software\ viewing them with RegEdit and using 'reg query ' in a normal console window.
Using the VS Command Prompt I perform the same query and get registry entries prior to my updates. If I open up a VS 2012 command prompt and perform edits using command line arguments the registry for that VS 2012 command prompt is now different than the registry read by the VS 2010 command prompt. It is also different from the VS 2012 IDE and the application built from VS 2012. They seem to have their own instances of whatever version of the registry they are reading from.
Finally, I opened up the Visual Studio 2012 command prompt and typed Regedit. It opened up RegEdit and it was viewing the old registry! All of the stale values within HKLM\Software\ were present - a seemingly completely separate version of the registry. Where is it getting this from?
My environment: Windows 7 Enterprise, VS 2012 Ultimate, console application built in 64-bit.
It should be noted that I have not made any major environment changes that I recollect and this is a new issue on my previously working development system. My colleagues have the same/similar environment and hardware setups with the same code base and have never encountered or seen this issue.
Things I've tried.
The almighty reboot
Uninstalling / Re-installing VS Studio 2012 as well as wiping out my code base, pulling it fresh and rebuilding (brute force I know...).
Checking the Registry for Wow6432Node keys to see if the reads/writes are getting redirected (I do not have a HKLM\Software\Wow6432Node and no other instances of that key have the old stale data or much else for that matter)
Searching the entire registry for the stale keys/values/data I'm seeing (not found anywhere)
Turning off virtualization using 'reg FLAGS hklm\software\ SET DONT_VIRTUALIZE DONT_SILENT_FAIL RECURSE_FLAG' as well as variations of this with one flag at a time.
Writing and debugging a unit test to try and determine anything.
VS 2012 safe mode
VS 2012 logging to see if the log file could shed any light on the problem.
Cursing (quietly because I'm at work)
Bribes (my workstation has yet to respond to these attempts)
Any help would be greatly appreciated. I'm close performing a clean Windows installation on my workstation but would rather save myself the time and trouble of setting everything up again :)
How can I find out where a Visual C++ security check is failing on a remote computer?
I have been brought on to a project to assist and am using the Visual Studio 2013 which has the /GS security checks to spot buffer overflows. This is great, and I don't want to turn them off, but they are causing the software to "crash" on a particular computer and I am struggling to find a way to know where. The normal tools to trap and log exceptions cannot be used. Dr Watson appears to be no longer supported, and I cannot remote debug to the computer.
I would appreciate a pointer to the appropriate tool to learn what the stack was when it failed the security check. Thank you.
Thanks to Hans and James, the answer is as follows:
First, on the remote machine that is having the problem, enable the mini-dump for the executable. Details are in Collecting User-Mode Dumps but in essence is to create a key for the name
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
DumpFolder = REG_EXPAND_SZ "c:\Path\To\Folder"
DumpCount = REG_DWORD 0x00000001
DumpType = REG_DWORD 0x00000002
So with that done, have your secure application crash, and you get a .dmp file in that folder.
Okay, now you have to make use of it in Visual Studio. This is quite easy too. Fully described in Post-Mortem Debugging Your Application with Minidumps and Visual Studio .NET (don't worry about the .Net part, that's not relevant), you just do a file open in Visual Studio (with no other project open, and not opening a solution but a file), and select the Dump files type. Open the file, and it has a "Run" item shown in the IDE. That opens the file as it was when it failed, and shows the exception type. The call stack for your module is all shown, and that should be enough of a clue to know where it went bang, and how to fix it.
Good luck!
I'm writing a console app for SharePoint 2013 on a 64-bit machine. I get this error when I try to execute the program:
"Microsoft SharePoint is not supported in 32-bit process. Please verify that you are running in a 64-bit executable."
Please let me know if you've had this problem in the past and can help. Thank you!
Have you checked the the properties for your project? (solution explorer, right click on the project, click on properties)
On the build tab check for that you select "Any CPU".
This worked for me:
In Visual Studio: TOOLS>OPTIONS>Projects and Solutions>WEB PROJECT and Use the 64 bit versions of IIS Express for web sites and projects
I hit this problem while running a Unit Test (well, an integration test in "Unit Test" clothing). Changing the target for the unit test project just made the tests disappear from the Test Explorer. It is possible to run your tests (at least in VS2013+) as an x64 environment.
In Visual Studio, choose Test > Test Settings > Default Processor Architecture > x64.
https://msdn.microsoft.com/en-us/library/ee782531(v=vs.120).aspx
Sometimes, if "Prefer 32-bit" is greyed out, and your Platform Target is already "Any CPU", the problem is that IIS Express is not 32 bit.
The solution is to change the solution's web server to Local IIS.
This blog details the steps in more detail:
Platform Not supported Exception when running Visual Studio Web Application
What worked for me was changing a registry key:
HCU\Software\Microsoft\VisualStudio\12.0\WebProjects\Use64BitIISExpress
to 1, as shown here:
https://rule30.wordpress.com/2015/06/22/microsoft-sharepoint-is-not-supported-in-32-bit-process-please-verify-that-you-are-running-in-a-64-bit-executable/
I got the same issue. The Build tab has the option Any CPU, but still it was not working.
I have selected explicitly x64 as the Platform target, and the application works fine :)
for me it was because of invalid reference to Microsoft.Shareppoint.dllafter migrating to SharePoint 2013 in a console application we used for some automation
just add below address of Microsoft.Shareppoint.dll
Correct
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.dll
you can found this reference to this correct dll , after creating a empty SharePoint 2013 project in your UAT.
I was getting this error inside my Windows 2012 R2 UAT and Visual Studio 2015 Update 1 , when my reference was incorrectly to a dll found in GAC
Incorrect
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SharePoint\v4.0_15.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll
When I start up VS 2012 RC I get the following loading error message:
The 'SqlStudio Profile Package' package did not load correctly.
The problem may have been caused by a configuration change or by the installation
of another extension. You can get more information by examining the file
'C:\Users\User\AppData\Roaming\Microsoft\VisualStudio\11.0\ActivityLog.xml'.
I also have SQL Server 2012 RTM installed.
What can I do to get rid of this warning?
Open Control Panel
Open Programs and Features
Locate all items named “Microsoft SQL Server 2012 Data-Tier App Framework"
Note: There might be up to 4 such instances all with the above name
Right click each of them and select Repair
That should solve this issue.
Janaka solution worked for me.
But if you do not want to lose your VS configuration, remove only the file :
Microsoft.VisualStudio.Default.cache
from the folder
%UserProfile%\AppData\Local\Microsoft\VisualStudio\11.0\ComponentModelCache
Hope it helps.
Remove the following folders.
C:\Users\UName\AppData\Roaming\Microsoft\VisualStudio\10.0
C:\Users\UName\AppData\Local\Microsoft\VisualStudio\10.0
See this
It turns out that (in my case), the Data Tools installer has a bug whereby you end up with a registry full of:
Microsoft Visual Studio 11.0Common7
...paths, when it should be:
Microsoft Visual Studio 11.0\Common7
Fixing all the values and keys fixes the problem (for me).
(ps: no other solution in this thread worked for me)
Just reinstall SQL Server Data Tools (SSDT)
I had to run VS as an administrator in order to clear this issue.
Problem: The 'SqlStudio Profile Package' package did not load correctly.
Proven Solution:
Removing Microsoft.VisualStudio.Default.Cache fixes the problem outlined above. It worked!
When I compile my SharePoint 2007 solution on a 64-bit machine in Release mode and the platform set to AnyCPU or x86 I get the following error:
An attempt was made to load an assembly with an incorrect format: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.Server.Search.dll.
When I use .Net Reflector on Microsoft.Office.Server.Search.dll it says the platform is set to x64. So I change my settings to Release mode and the platform to x64 and get the same error.
The strange thing is when I change Release to debug, It complies. Can anyone explain this?
I would prefer compiling with the settings Release/AnyCPU if its possible. Can anyone give me a push in the right direction?
Thanks
p.s. I also asked the question here: http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/21d14405-ca6f-4503-b416-f56bfb27168b/
I too have experienced this same issue, for me it seemed that my changes to the build configuration weren't actually taking. After several attempts at saving, reopening project, choosing build/rebuild, I was able to get it functioning after choosing "Clean" from the build options.