Visual Studio 2015 Community update 3, trying the C++ code analysis feature. The settings are as follows:
solution properties > code analysis settings > [all configurations] [all platforms] : microsoft native recommended settings
project properties > code analysis > [all configurations] [all platforms] : microsoft native recommended settings
Whenever I run analyze > run code analysis on solution I would always get a c1xx : fatal error C1253: Unable to load model file 'res://mspft140.dll/300'. This happens to every project, new or existing. MSDN is not particularly helpful about this one.
The string is a res protocol, so I checked if the dll mentioned is at its correct location (there are two actually, at c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\ and c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64), and opened them with resedit. Both contain an XML resource named 300, so I don't see any reason for VS being unable to load it. Resetting the settings didn't help, full uninstall and reinstall (half a day wasted) did neither.
I also ran procmon with [Path] [contains] [mspft] filter while running the code analysis in VS, but the file system results are only SUCCESS and FILE LOCKED WITH ONLY READERS, which seems to be ok.
Did anyone experience this error? Does anyone have any surmises about its cause?
Update: After looking thoroughly through many more procmon captures with different filters I found out that cl.exe tries to open this registry key value: HKCR\PROTOCOLS\Handler\res\CLSID. Clearly it looks for the handler of the res protocol mentioned in the error output - and it's not there to be found, while many siblings of res key refer to some valid handlers, for example, http key has CLSID value of {79eac9e2-baf9-11ce-8c82-00aa004ba90b}. I guess that my quest for now is figuring out what that res CLSID is meant to be.
I was right in my assumption about the res protocol handler. The correct HKCR\PROTOCOLS\Handler\res\CLSID value is {3050f3bc-98b5-11cf-bb82-00aa00bdce0b} (which refers to C:\Windows\System32\mshtml.dll). For some reason my registry was missing it; as soon as I added the value, the code analysis started working without errors.
I hope this helps someone, although I believe the bug is extremely rare.
Related
Ever since I updated Visual Studio 2022 from 17.1 to 17.2, I have been having a problem with my C++ project build failing without emitting an error message in the IDE Output window, no matter the diagnostic level selected in the Tools->Options->Projects and Solutions->Build Options menu.
I have tried:
Reinstalling Visual Studio 2022
Deleting .vs folders(s)
Deleting the x64 folder
These are all suggested in answers to similar questions from several years ago that I have read here.
It definitely seems to have something to do with being on a network share from my Mac. I cloned my repository locally and the problem went away. Meanwhile, I cloned my repository to a different directory on the network share, and it continued to fail in the new directory.
I have discovered an error message buried in C:\Users\<user>\AppData\Local\Temp in a file named MSBuild_pid-<guid>.failure.txt. It appears to be correlated to the failure. Here is the error message:
UNHANDLED EXCEPTIONS FROM PROCESS 624:
=====================
6/20/2022 8:49:39 AM
Microsoft.Build.Framework.LoggerException: Failed to write to log file "Y:\<filepath>.log". IO operation will not work. Most likely the file will become too long or the handle was not opened to support synchronous IO operations.
at Microsoft.Build.Logging.FileLogger.Write(String text)
at Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.WriteMessageAligned(String message, Boolean prefixAlreadyWritten, Int32 prefixAdjustment)
at Microsoft.Build.BackEnd.Logging.ParallelConsoleLogger.ErrorHandler(Object sender, BuildErrorEventArgs e)
at Microsoft.Build.Framework.BuildErrorEventHandler.Invoke(Object sender, BuildErrorEventArgs e)
at Microsoft.Build.Utilities.MuxLogger.SubmissionRecord.RaiseErrorEvent(Object sender, BuildErrorEventArgs buildEvent)
at Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseErrorEvent(Object sender, BuildErrorEventArgs buildEvent)
at Microsoft.Build.BackEnd.Logging.LoggingService.RouteBuildEvent(KeyValuePair`2 nodeEvent)
at Microsoft.Build.BackEnd.Logging.LoggingService.RouteBuildEvent(Object loggingEvent)
at Microsoft.Build.BackEnd.Logging.LoggingService.LoggingEventProcessor(Object loggingEvent)
===================
This is similar to a question I posed a couple of weeks ago, but since the nature of the question is now more focused and has an apparent error message, I deleted that question and am reposting this issue as a new question for visibility and to avoid confusion.
[EDIT]
I decided to go fish out the actual log file in the message above. It turns out Visual Studio is not having any trouble writing to it. And it terminates in another error message:
RGPLua.cpp
RGPLuaConnector.cpp
RGPLuaConnectorBase.cpp
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.29.30133\include\type_traits(59,92): fatal error C1001: Internal compiler error.
It is unclear to me which message is the cause and which is the effect. However, after running it several times it is worth noting that the error and file location given in the log file is different each time while the message in the MSBuild_pid file is always the same.
So I tried making a basic game on the console using screen buffers, I was able to create it and make a square move in the canvas, but for my next project I looked up a website with the ASCII characters and pasted a couple into a comment at the end of the c++ file, when I ran the file visual studio prompted:
I clicked yes and it didn't run anymore.
Also I recently have installed an extension for visual studio (before it didn't run, the extension works fine but I don't know if the extension may have caused this as I didn't tried running it with the extension downloaded and applied), when I open visual studio and open a file it says:
The last record in the ActivityLog xml file, has a type of error and it's description is:
Microsoft.VisualStudio.Composition.CompositionFailedException: Expected 1 export(s) with contract name "Microsoft.VisualStudio.CppSvc.Internal.CodeAnalysis.ICodeAnalysisService" but found 0 after applying applicable constraints.
at Microsoft.VisualStudio.Composition.ExportProvider.GetExports(ImportDefinition importDefinition)
at Microsoft.VisualStudio.Composition.ExportProvider.GetExports[T,TMetadataView](String contractName, ImportCardinality cardinality)
at
Microsoft.VisualStudio.Composition.ExportProvider.GetExport[T,TMetadataView](String contractName)
at
Microsoft.VisualStudio.Composition.ExportProvider.GetExport[T](String contractName)
at
Microsoft.VisualStudio.Composition.ExportProvider.GetExportT
at
Microsoft.VisualStudio.Composition.ExportProvider.GetExportedValueT
at Microsoft.VisualStudio.ComponentModelHost.ComponentModel.GetServiceT
at Microsoft.VisualStudio.VC.ManagedInterop.<>c.<Initialize>b__52_15()
at
System.Lazy`1.CreateValue()
at
System.Lazy`1.LazyInitValue()
at
System.Lazy`1.get_Value()
at
Microsoft.VisualStudio.VC.CodeAnalysis.ResultTaggerProvider.CreateTagger[T](ITextBuffer buffer)
at
Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator`1.GatherTaggers(ITextBuffer textBuffer)
--- End of stack trace from previous location where exception was thrown ---
at
Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
I have Visual Studio 2017
So why does running the file (with the local windows debugger button) say that there were build errors? And how can I fix it?
When it prompts the build error, and I click no it usually shows the errors but in this case it doesn't, yes will just run the last "successful" build (although I haven't changed the file since I have finished it before this error message started popping up)
Also there is no error in my code as I was able to run it before the build error kept appearing and I haven't touched the file since(only now to show the problems are)
Thanks for your time! if anything was unclear because of my English, comment and I'll try to clarify it
I fixed the error by deleting ComponentModelChache folder located at:
C:\Users\%userName%\AppData\Local\Microsoft\VisualStudio\15.0
15.0 is the version of your visual studio so it varies depending on the version you're using, %userName% is a replacement for the user you're logged in as
I'm having a weird error after updating Visual Studio 2019 Community from v16.4.5 to 16.5. Even a fresh install of the engine will no longer build. I'm getting the errors listed below. The build doesn't fail until the end of compiling all modules:
Error C4800 Implicit conversion from 'ADODB::_Recordset *const ' to bool. Possible information loss UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\INCLUDE\comip.h 311
Error C4800 Implicit conversion from 'ADODB::_Connection *const ' to bool. Possible information loss UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\INCLUDE\comip.h 311
Error MSB3075 The command "..\..\Build\BatchFiles\Build.bat -Target="UE4Editor Win64 Development" -Target="ShaderCompileWorker Win64 Development -Quiet" -WaitMutex -FromMsBuild" exited with code 5. Please verify that you have sufficient rights to run this command. UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets 44
I have not changed or updated anything on the Unreal Engine-side of the code. This error occurs during a build of UE4.sln, sourced from Epic's github repo. The build doesn't fail until all modules are built (it fails at the end of the build).
Seeing as Microsoft doesn't have archives of installers for VS Community, only Enterprise and Pro, I'm kind of suddenly stuck here because I can't just uninstall 16.5 and reinstall 16.4.5 (which is the last working version I was on before the update).
I heard sometimes setting "treat warnings as errors" to false can help, but I don't see a way to do that in Visual Studio.
Any insight into this would be helpful, Thanks!
So, turns out something changed on VS2019's side in the update from 16.4.5 to 16.5, but the fix for UE4 can be found in this commit on the 4.25 branch. Confirmed that this solved my problem!
First Make a backup of your whole project (just copy it to somewhere else).
Afterwards delete the following folders in the project directory:-
.vs
Intermediate
Saved
you just need to delete the .vs folder to solve the problem. The rest are just for a quick refresh of your project.
Next open Unreal Engine 4, then under File tab click on Refresh Visual Studio Project. On completion try to compile again. This should solve your problem.
For those who facing the same problem, here is the solution.
Step 1:
open the file ADOSupport.cpp on [YourEngineSourceDir]\Engine\Plugins\Runtime\Database\ADOSupport\Source\ADOSupport\Private
Step 2:
go to line 255 and modify it
from if(ADORecordSet && (ADORecordSet->State & ADODB::adStateOpen))
to if(ADORecordSet != nullptr && (ADORecordSet->State & ADODB::adStateOpen))
Step 3:
got to line 328 and modify it from if( DataBaseConnection && (DataBaseConnection->State & ADODB::adStateOpen)) to if( DataBaseConnection != nullptr && (DataBaseConnection->State & ADODB::adStateOpen))
Step 4: Build the solution and enjoy!
You should add the new line of code, like on the video tutorial:
Arguments.Add("/wd4800"); // 4800: Implicit conversion from 'type' to bool. Possible information
https://youtu.be/KXIv4y51fyw
That fix me that issue.
I had the same issue, and this solved it:
File Path
YOURENGINEPASS\Engine\Source\Programs\UnrealBuildTool\Platform\Windows
File to change
VCToolChain.cs
After line 456 add the following line:
Arguments.Add("/wd4800"); // 4800: Implicit conversion from 'type' to bool. Possible information
I am using VS2010 (pro) and VS2015 Express.
Recently (probably as a result of installing some other software) all my 32 bit builds started failing with
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" #C:\Users....rsp". The handle is invalid.
(64 bit builds continue to work)
The problem appears to be MSBuild invoking the 64 bit version of Tracker.
Google tells me that others have had the opposite problem in that 64 bit builds get the same error, whilst 32 bit builds succeed
Looking at procmon I find that MSBUILD
(1) opens Registry Key
HKLM\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full
which has an InstallPath value of
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
(2) tries to open C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Tracker.exe which does not exist
(3) opens registryKey
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86
(which does not exist, although
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1A\WinSDK-NetFx40Tools-x86
does)
(4)opens file
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\Tracker.exe
Which generates the error above
I'm at a loss to explain the presence of the "x64", especially as MSBuild appears to be looking for a file path in a registry key that ends in -86
From http://community.sharpdevelop.net/forums/p/11439/31258.aspx there is a wordaround to disable tracker by adding
"False" to a property group in the .vcxproj file.
But this entails changing many such files
Any advice welcome
I've been able to solve the same issue by making sure _IsNativeEnvironment environment variable is set to false.
I am currently trying to upgrade our c++ mfc solution from visual studio 2010 to a visual studio 2013 solution. When i try to build it i get the error MSB4018 The "ResolveComReference" task failed unexpectedly. I enabled fusion logging and this is what it tells me:
=== Pre-bind state information ===
LOG: DisplayName = System
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: System | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Build.Tasks.v12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. ===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.EXE.
I understand that msbuild has been moved, but i dont understand why it is trying to find System.dll in the msbuild path, how can i make it look for it in its proper location?
Edit:
I have now also tried upgrading to visual studio 2012 which worked without bigger problems and I did not run into the same problem. However i noticed that when running devenv /upgrade (with vs2013) it seems to completely change everything under vc++ directories (it stayed unchanged when upgrading to vs2012). Could this have something to do with this issue?
Edit2:
Tried to build the project in vs2013 after upgrading it to 2012 (without running devenv /upgrade), this also didnt work so I guess the problem is not related to that...
After enabling diagonostic build output i found that it was 3 broken COM references in the project that where failing to load. Removing these references solved the building issue. These where only showing up as warnings in vs2010 but resulted in MSB4018 in vs 2013 for some reason.
This is your problem:
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
Fix the base folder in your build system if you really need it to point to another filder. However it would probably be better to redo you build system targeting 2013 instead of patching the 2010 version.