Skip to content
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.

Can't build native UWP app. ILC.exe, always a 32-bit image, fails with: Internal compiler error: Exception of type 'System.OutOfMemoryException' was thrown. #5905

Closed
cwrea opened this issue Jun 6, 2018 · 8 comments
Labels

Comments

@cwrea
Copy link

cwrea commented Jun 6, 2018

I'm trying to build a UWP unit test app in Release mode using the Compile with .NET Native tool chain option enabled. My UWP app's minimum and target versions are both set to Windows 10 build 16299. I'm using Visual Studio 15.7.3, and the build always fails because ILC.exe runs out of memory:

Internal compiler error: Exception of type 'System.OutOfMemoryException' was thrown.

I could see that the ILC.exe executable is a 32-bit image and isn't able to take advantage of most of the 32GB memory available on my box. ILC.exe failed after allocating about 3.4GB memory.

I tried to get Visual Studio to invoke a 64-bit ILC.exe using in each of the following ways, but ILC.exe is, according to Process Explorer, always running as a 32-bit process.

  1. I tried adding <UseNativeEnvironment>true</UseNativeEnvironment> to my UWP project's default <PropertyGroup> element. I found a mention of this in relation to Visual C++, so I might have been barking up the wrong tree for a C# app on UWP.

  2. I tried adding <Use64BitCompiler>true</Use64BitCompiler> to my UWP project's default <PropertyGroup> element. I had found this mentioned at Net Native compilation fails with Out of Memory (Xamarin/UWP) #5604.

  3. I tried explicitly referencing the package runtime.win10-x64.Microsoft.Net.Native.Compiler v2.1.8 in my UWP project. The package description says:

    .Net Native Compilers package. Referencing this package will cause the project to be built using the specific version of the .NET Native compiler contained in the package, as opposed to any system installed version.

While it does appear that the correct package folder is referenced and a tools\x64\ilc\ilc.exe image is being executed by Visual Studio, the ILC.exe process remains a 32-bit process even despite the x64 claimed by parent folder naming. Here's what Process Explorer shows:

ilc_not_x64

Am I doing something wrong?

Or is the ILC.exe that is shipped as part of runtime.win10-x64.Microsoft.Net.Native.Compiler actually a 32-bit program image and not a 64-bit program image? And if it is actually a 32-bit program image, is that by design, or an oversight?

How can I get my UWP app building with the native tool chain? Thank you.

@MichalStrehovsky
Copy link
Member

We don't have a 64-bit version of ILC.exe, unfortunately.

Could you try placing <ShortcutGenericAnalysis>true</ShortcutGenericAnalysis> in one of your property groups?

This will try to shortcut analysis of generic code (if that's the problem) and might fix the issue for you. We recommend re-testing your app since it might make the analysis miss reflection patterns or serialization uses (it's possible to manually fix those later with RD.XML if that happens) and shouldn't be a big problem.

@jkotas jkotas added the ProjectN label Jun 8, 2018
@cwrea
Copy link
Author

cwrea commented Jun 8, 2018

I'll try that shortly, thanks. But, re:

We don't have a 64-bit version of ILC.exe, unfortunately.

Perhaps note that in the package description, somehow? The naming runtime.win10-x64.Microsoft.Net.Native.Compiler can lead one to believe the whole set of tools would be x64, as opposed to just some of the bits.

@MichalStrehovsky
Copy link
Member

The runtime.win10-x64 part refers to the compilation target (the architecture that the compiler compiles for). There's also runtime.win10-x86.Microsoft.Net.Native.Compiler and runtime.win10-arm.Microsoft.Net.Native.Compiler. It's not the architecture of the compiler EXE. I know it's confusing, but compilers are confusing.

@cwrea
Copy link
Author

cwrea commented Jun 13, 2018

@MichalStrehovsky I just got around to trying this with the option you mentioned above, <ShortcutGenericAnalysis>true</ShortcutGenericAnalysis>. The build of my sample app succeeded for the first time with the .NET Native tool chain enabled. Thank you.

I looked for information about this ShortcutGenericAnalysis option, but I can't find anything about it — Google has no relevant hits other than this same issue. Is ShortcutGenericAnalysis an official setting, or a private setting for troubleshooting issues such as this one?

FWIW, while building I was closely watching memory usage for both the ilc.exe and nutc_driver.exe processes in Process Explorer. This time, ilc.exe did not exceed ~1.9GB (private bytes). Interestingly, nutc_driver.exe got as high as 6.7GB (private bytes). Why is nutc_driver.exe a 64-bit image, while ilc.exe is not?

@MichalStrehovsky
Copy link
Member

Glad you got unblocked.

I think the ShortcutGenericAnalysis option is something we are planning to enable by default. Right now we offer it just as an escape hatch with the "We recommend re-testing your app" warning that I wrote above. Cc @morganbr on that.

nutc_driver.exe is the native code generator. It typically has to generate native code and debug information for 200,000+ methods, while maintaining whole program analysis information about all of it. It uses more memory and that's why we ship a 64bit version.

Ilc.exe has no right to use that much memory because it doesn't do that kind of work. The only legit use case of Ilc.exe needing more than 3 GB of memory is when someone puts hundreds of megabytes of data into managed resources. Ilc.exe unfortunately maps all of it into its address space and things get pretty tight. We might end up shipping a 64bit version of it, but just because of that.

@gtbuchanan
Copy link

gtbuchanan commented Aug 1, 2019

Has any progress been made on a 64-bit version of ilc?

I'm on VS 16.2.0 with UWP 6.2.8 and I am receiving the same error as the OP. However, all the ShortcutGenericAnalysis workaround does is give me another error:

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0400: The type or namespace name 'Ewn' could not be found in the global namespace (are you missing an assembly reference?)
error CS0400: The type or namespace name 'Ewn' could not be found in the global namespace (are you missing an assembly reference?)
    at System.Xml.Serialization.Compiler.Compile(XmlSerializerCompilerParameters xmlParameters, Evidence evidence, String
    at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Hashtable assemblies, String outputDir, String assemblyNameBase, IEnumerable`1 referenceDirectories, String intermediateDir, Boolean loadAssembly)
    at System.Xml.Serialization.XmlSerializer.GenerateSerializer(Type[] types, XmlMapping[] mappings, CompilerParameters
    at System.Xml.Serialization.XmlSerializer.GenerateSerializer(Type[] types, String outputDir, String assemblyNameBase,
    at SerializationAssemblyGenerator.Program.Main(String[] args)
Generating System.Reflection.DispatchProxy proxy code.
error : ILT0032: Failed to compile serialization code. See the build log for error details.

I assume these are related to missing entries in rd.xml, but the error message is worthless since we have many projects/packages with the namespace Ewn. Detailed build log doesn't show any more details as to what specific types or child namespace is the issue. I've tried adding the following (and many others), but recieve the exact same error message:

<Namespace Name="Ewn" Serialize="All" />

@MichalStrehovsky
Copy link
Member

@gtbuchanan Compilation failures are never a manifestation of missing RD.XML entries. This looks like a bug. Can you reach out to dotnetnative at microsoft com? We're better equipped to help there.

@tipa
Copy link

tipa commented Nov 28, 2019

I am hitting a similar problem as well when building in Azure Pipelines. I have all these flags set in my .csproj:

<Use64BitCompiler>true</Use64BitCompiler>
<SingleThreadNUTC>true</SingleThreadNUTC>
<ShortcutGenericAnalysis>true</ShortcutGenericAnalysis>

The error message is not mentioning "OutOfMemoryException" however:

Launching 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x86.microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\x86\ilc\Tools64\nutc_driver.exe @"d:\a\1\s\myapp\myapp.UWP\obj\x86\Release\ilc\intermediate\MDIL\myapp.rsp"'
##[error]C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): Error : Internal Compiler Error
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): error : Internal Compiler Error [d:\a\1\s\myapp\myapp.UWP\myapp.UWP.csproj]
##[error]C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): Error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x86.microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\x86\ilc\Tools64\nutc_driver.exe @"d:\a\1\s\myapp\myapp.UWP\obj\x86\Release\ilc\intermediate\MDIL\myapp.rsp"' returned exit code 1
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-x86.microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\x86\ilc\Tools64\nutc_driver.exe @"d:\a\1\s\myapp\myapp.UWP\obj\x86\Release\ilc\intermediate\MDIL\myapp.rsp"' returned exit code 1 [d:\a\1\s\myapp\myapp.UWP\myapp.UWP.csproj]
Done Building Project "d:\a\1\s\myapp\myapp.UWP\myapp.UWP.csproj" (default targets) -- FAILED.

Anything else that I could try?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants