Interesting bugs - MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small.
I got a very strange warning recently when building a .NET Core app with "dotnet build."
MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible.
Image is too small.
Eek! It's clear, in that something is "too small" but what? A file I guess? Maybe it's the wrong size?
The error code is MSB3246 which is nice and googleable/searchable but it was confusing because I couldn't figure our what file specifically. It just felt vague.
BUT!
I had recently been overclocking my machine (overly aggressively, gulp, about 40%) and had a very nasty hard reboot. As a result I had a few dozen files get orphaned - specifically the files were zero'ed out! Zero is small, right?
Turns out you can pass parameters over to MSBuild from "dotnet build" and see what MSBuild is doing internally. For example, you could
/fileLoggerParameters:verbosity=diagnostic
but that's long. So how about:
dotnet build /flp:v=diag
Cool. What deep logging do I see now?
Primary reference "deliberately.zero.bytes.dll". (TaskId:41)
13:36:52.397 1:7>C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
Resolved file path is "S:\work\zero-byte-ref\deliberately.zero.bytes.dll". (TaskId:41)
Reference found at search path location "{RawFileName}". (TaskId:41)
Now with "verbose" turned on I can see that one of the references is zero'ed out/corrupted/bad. I reinstalled .NET Core in my case and doubled checked all the DLLs/Assemblies that I was bringing in - I also ran chkdsk /f - and I was back in business!
I hope this helps someone who might stumble on error MSB3246 and wonder what's up.
Even better, thanks to Rainer Sigwald who filed a bug against MSBuild to update the error message to be more clear. In the future I'll be able to debug this without changing verbosity!
Sponsor: Preview the latest JetBrains Rider with its built-in spell checking, initial Blazor support, partial C# 7.3 support, enhanced debugger, C# Interactive, and a redesigned Solution Explorer.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Previously, some projects did this to ship native DLLs.
See on StackOverflow
How come developer tools don't get the same level of reliability as does SQL Server?
No one would buy SQL Server if your only upgrade path every 3 years is to edit config files, rewrite c# code, rebuild your server machine, update all of your SQL queries, install and learn 10 different new open source software of unknown reliability.
Why does MS development not get held to the same quality, upgrade path and stability standard as SQL Server?
It's costing my large team thousands, if not tens of thousands, of dollars in lost money every year.
Please help.
Comments are closed.
Have asked many times to get th field name causing an exception when initializing an object
Devops is sold Sa cure but is not followed in the compiler or visual studio
Had to attach visual studio debugger to another visual studio instanc to catch a compiler exception