largeaddressaware:no is not recommended for 64-bit apps

[mspll]

No description provided.

[prmerger-automator]

@mspll : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit 9e0875b:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/reference/largeaddressaware-handle-large-addresses.md	✅Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[Jak-MS]

@TylerMSFT

• Can you review this PR?
• IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[TylerMSFT]

Hi @mspll,
Thank you for taking the time to contribute to the docs!
I'd like to take this contribution but would like to tone down the 'result in runtime failures' part. The way it is written implies that using the switch can generate runtime failures. As you know, the problem is that memory usage is limited to 2gb, and if your program fills it up (which most don't come close to) then you could potentially hit a runtime error. But I don't want to imply that the switch results in runtime failures. Can you update?

[mspll]

@TylerMSFT One case where this causes runtime failures is trying to run a non-large-address-aware x64 EXE on an ARM64 system. The emulation runtime tries to reserve a 4 GB region of VA space and fails, so the process doesn't even start.

(This scenario is what prompted this doc update)

[GitTyler]

That's an interesting scenario. What do you think about something like this, then:

Linking 64-bit applications with /LARGEADDRESSAWARE:NO is not recommended. It restricts the amount of available address space available to your app which can result in runtime failures if the app exhausts memory. It may also prevent x64 apps from running on ARM64 systems because the emulation runtime will try to reserve 4GB of virtual address space. If the app was linked with /LARGEADRESSAWARE:NO, the app won't launch because allocating that much address space will fail.

Awesome of you to update this page as a result of your experience!

[learn-build-service-prod]

Learn Build status updates of commit 322d380:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/reference/largeaddressaware-handle-large-addresses.md	✅Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[learn-build-service-prod]

Learn Build status updates of commit 5f75e0d:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/reference/largeaddressaware-handle-large-addresses.md	✅Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[learn-build-service-prod]

Learn Build status updates of commit a0921a7:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/build/reference/largeaddressaware-handle-large-addresses.md	✅Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[TylerMSFT]

#sign-off