Editbin /LARGEADDRESSAWARE

[Frank Rizzo]

My .NET 2.0 app may be deployed on both 32-bit and 64-bit systems.
Are there any side effects to running Editbin /LARGEADDRESSAWARE against
the EXE and then deploying it on a 64-bit system?

The reason I ask is that there is just one setup and the .EXE will be
converted to be LARGEADDRESSAWARE at setup creation time.

Thanks.

 

[Luke Zhang [MSFT]]

Hello,

So far, I didn't see any reported problem caused by "Editbin
/LARGEADDRESSAWARE" against an .NET assembly. It will indicate that the
assembly can handle addresses larger than 2 gigabytes and this is required
on a 64-bit system. Anyway, since your application will be deploy on both
32-bit and 64-bit system, there may be some potential issues. You need to
perform complete test on these two platform including the setup process.

Sincerely,

Luke Zhang

Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Frank Rizzo]

Hello,

So far, I didn't see any reported problem caused by "Editbin
/LARGEADDRESSAWARE" against an .NET assembly. It will indicate that the
assembly can handle addresses larger than 2 gigabytes and this is required
on a 64-bit system. Anyway, since your application will be deploy on both
32-bit and 64-bit system, there may be some potential issues. You need to
perform complete test on these two platform including the setup process.

Wow, this makes no sense. You are saying that a .NET 2.0 compiled
executable won't be able to access more than 2 GB of RAM on a 64-bit OS,
unless it's been tweaked with 'Editbin /LARGEADDRESSAWARE'???

My understanding is that out of the box .NET 2.0 compiled EXEs can
access 1TB of RAM (or some such ridiculous number) on a 64-bit OS.

But to be able to access 3GB on a 32-bit OS, you had to run the EXE
through 'Editbin /LARGEADDRESSAWARE'.

Is this not the case?

 

[Willy Denoyette [MVP]]

My .NET 2.0 app may be deployed on both 32-bit and 64-bit systems.
Are there any side effects to running Editbin /LARGEADDRESSAWARE against the EXE and then
deploying it on a 64-bit system?

The reason I ask is that there is just one setup and the .EXE will be converted to be
LARGEADDRESSAWARE at setup creation time.

Thanks.

Question is - why do you 'flag' this application to be LARGEADDRESSAWARE?
Does the application really needs more than the default 2GB VAS?
What target platform (AnyCPU, x86, x64) did you specify while compiling?
Following illustrates the effect of the target platform and the LAA flag on the VAS:

AnyCpu (default)
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = xTB (default)
x86
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = 2GB (default)
64 bit OS LAA VAS = 4GB
x64
64 bit OS VAS = xTB

LAA = LARGEADDRESSAWARE
x = 6 or 7 TB

It's clear that you need to know your specific VAS requirements before you can decide to
apply the LAA flag.
It's obvious that your application will need to restrict it's VAS requirements to < 3GB,
otherwise it won't run on 32Bit. However, if you apply the LAA on an AnyCpu target, nothing
stops it from consuming more than 3GB on 64 bit, that's why I would never compile with the
AnyCpu flag if I have very specific memory requirements.

Willy.

 

[Frank Rizzo]

Question is - why do you 'flag' this application to be LARGEADDRESSAWARE?
Does the application really needs more than the default 2GB VAS?
What target platform (AnyCPU, x86, x64) did you specify while compiling?
Following illustrates the effect of the target platform and the LAA flag
on the VAS:

AnyCpu (default)
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = xTB (default)
x86
32 bit OS VAS = 2GB (default)
32 bit OS LAA VAS = 3GB
64 bit OS VAS = 2GB (default)
64 bit OS LAA VAS = 4GB
x64
64 bit OS VAS = xTB

LAA = LARGEADDRESSAWARE
x = 6 or 7 TB

It's clear that you need to know your specific VAS requirements before
you can decide to apply the LAA flag.
It's obvious that your application will need to restrict it's VAS
requirements to < 3GB, otherwise it won't run on 32Bit. However, if you
apply the LAA on an AnyCpu target, nothing stops it from consuming more
than 3GB on 64 bit, that's why I would never compile with the AnyCpu
flag if I have very specific memory requirements.

Willy, thank you for your reply. It's informative as always. In
answers to questions you posed:

1. Yes, the application does need more than 2GB of RAM for some of my
larger customers. Usually the application consumes 2.1-2.3GB at the
most. Typically, the customers have multi-proc boxes with around 6-8 GB
of RAM. However, some of these customers have 32-bit boxes, others have
64-bit. And I don't know who has what, so I need to cover all the
bases. Thus I specify AnyCPU.

2. So I need to make sure, that if customer has a 32-bit box, they can
access more than 2GB of RAM.

3. So I figured that if I marked an AnyCPU executable with LAA, then
I'll be covering all bases. If the user installed the app on a 32-bit
box, they would be able to use 3GB of RAM. If the app was installed on
the 64-bit box, they would use xTB of RAM.

Am I wrong?

Regards

 

[Frank Rizzo]

One more unrelated question. When deploying a 32-bit LAA enabled EXE to
the 64-bit OS, does the machine need the /3GB flag in order to access
4GB of RAM?

Regards

 

[Willy Denoyette [MVP]]

One more unrelated question. When deploying a 32-bit LAA enabled EXE to the 64-bit OS,
does the machine need the /3GB flag in order to access 4GB of RAM?

Nope.

Willy.

 

[Willy Denoyette [MVP]]

Willy, thank you for your reply. It's informative as always. In answers to questions you
posed:

1. Yes, the application does need more than 2GB of RAM for some of my larger customers.
Usually the application consumes 2.1-2.3GB at the most. Typically, the customers have
multi-proc boxes with around 6-8 GB of RAM. However, some of these customers have 32-bit
boxes, others have 64-bit. And I don't know who has what, so I need to cover all the
bases. Thus I specify AnyCPU.

If you never need more than 4GB, you better specify X86 as target. On a 32 bit OS you will
get up to 3GB while on 64 bit you'll get up to 4GB VAS.

2. So I need to make sure, that if customer has a 32-bit box, they can access more than
2GB of RAM.

This requires the/3GB boot.ini switch.

3. So I figured that if I marked an AnyCPU executable with LAA, then I'll be covering all
bases. If the user installed the app on a 32-bit box, they would be able to use 3GB of
RAM. If the app was installed on the 64-bit box, they would use xTB of RAM.

Right, but if you memory requirements are < 3GB (as they are), so you don't need the address
extention feature of the 64bit platform (HW and OS) anyway.
That's why I said you better target x86, that way you are sure that both run the exact same
code (both use the JIT32), both have the same memory footprint, that is the same workingset,
virtual bytes, stack requirements etc. and both use the same framework code on both 32 and
64 bit.

Willy.

 

[Frank Rizzo]

If you never need more than 4GB, you better specify X86 as target. On a
32 bit OS you will get up to 3GB while on 64 bit you'll get up to 4GB VAS.

This requires the/3GB boot.ini switch.

Right, but if you memory requirements are < 3GB (as they are), so you
don't need the address extention feature of the 64bit platform (HW and
OS) anyway.
That's why I said you better target x86, that way you are sure that both
run the exact same code (both use the JIT32), both have the same memory
footprint, that is the same workingset, virtual bytes, stack
requirements etc. and both use the same framework code on both 32 and 64
bit.

Ah, understood. I couldn't grok previously why you were recommending a
specific flag. Now it makes sense.

Regards