Scott Hanselman

Interesting bugs - MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small.

August 31, 2018 Comment on this post [7] Posted in DotNetCore
Sponsored By

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.

Interesting Bug used under CC https://flic.kr/p/4SpmL6Eek! 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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
September 01, 2018 8:50
Have asked many many times for the name of a missing file when loading an exe where a nested doll does not exist

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

September 01, 2018 20:40
Huh. It's worrisome that a random reboot corrupts the filesystem -- haven't seen that on Windows for, like, at least ten years... (Verbose logging is cool though :) )
Max
September 02, 2018 4:48
Another common reason for this error message is that native DLLs shouldn't be placed inside a lib/ folder in NuGet packages, but rather runtime/ (sub-)folders. Full framework MSBuild doesn't care but Core MSBuild (dotnet CLI) does - different APIs used for inspecting the .dll file AFAIK.
Previously, some projects did this to ship native DLLs.
See on StackOverflow
September 03, 2018 0:53
Scott, are you referencing the error from the Salesforce library conversion to .NET Core live stream?
September 05, 2018 3:15
Robert - Exactly right!
September 10, 2018 6:43
The level of verbosity "diagnostic" is almost unreadable because it contains to much text. However you can use the binary logger to get the same data but in a readable way: Exploring the MSBuild log using the binary log viewer
September 11, 2018 9:07
Scott,

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.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.