1

I wanna use more than 1.2 GB RAM.

So I tried the editbin /LAGEADRESSAWARE command.

The command executes with no error but still I get out of memory exceptions at 1.2 GB.

Now I ask myself: I have several exe files in my project. Which exe file(s) must be processed:

  1. all exe files
  2. the entry assembly [1]
  3. the executing assembly [1]

[1]: Term entry/executing as defined in System.Reflection.Assembly.GetEntryAssembly/GetExecutingAssembly)

I tried 2) and 3) and it has no effect.

The output of the editbin is just:

2>  Microsoft (R) COFF/PE Editor Version 11.00.61030.0
2>  Copyright (C) Microsoft Corporation.  All rights reserved.

Is this the right output?

phuclv
  • 37,963
  • 15
  • 156
  • 475
charly_b
  • 69
  • 10
  • Anyhow, some guys like to rate down my questions, i still ask myself whats wrong with it. It's likely that it's the executing assembly, but still it's a legit question, even if i would have made the mistake in test code as joshua assumed (but i didnt). So instead of just rating down it would be nice to write a comment whats wrong about the question.. – charly_b Dec 21 '17 at 10:08
  • It is already automatically turned on when you use the "Prefer 32-bit" checkbox. Not one you prefer when you get OOM and need a 64-bit OS anyway to stay out of trouble. Use the correct tool to look at it, dumpbin.exe /headers – Hans Passant Mar 26 '18 at 11:29

3 Answers3

1

To make sure it works, u need to use dumpbin, located in the same folder as editbin. It displays information about Common Object File Format (COFF) binary files. When /largeaddressaware is enabled, the we can see extra header "Application can handle large (>2GB) addresses"

               14C machine(x86)
                 3 number of sections
          5AB8D688 time date stamp Mon Mar 26 13:16:24 2018
                 0 file pointer to symbol table
                 0 number of symbols
                E0 size of optional header
               122 characteristics
                     Executable
                     Application can handle large(>2GB) addresses
                     32 bit word machine

if not enabled(default):

  FILE HEADER VALUES
               14C machine(x86)
                 3 number of sections
          5AB8D734 time date stamp Mon Mar 26 13:19:16 2018
                 0 file pointer to symbol table
                 0 number of symbols
                E0 size of optional header
               102 characteristics
                     Executable
                     32 bit word machine

From cmd:

>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\dumpbin" /headers C:\MyFile.exe

From VS post-buid event:

call "$(DevEnvDir)..\tools\vsvars32.bat"
editbin /largeaddressaware "$(TargetPath)"
dumpbin /headers "$(TargetPath)"

if there will be some errors then use your environment verion direclty:

call "$(VS100COMNTOOLS)..\tools\vsvars32.bat" // for vs 2012.
or
call "$(VS120COMNTOOLS)..\tools\vsvars32.bat" // for vs 2013.

or with conditions:

IF  EXIST  "%VS100COMNTOOLS%"  CALL  "%VS100COMNTOOLS%vsvars32.bat" 
IF  EXIST  "%VS110COMNTOOLS%"  CALL  "%VS110COMNTOOLS%vsvars32.bat" 
IF  EXIST  "%VS120COMNTOOLS%"  CALL  "%VS120COMNTOOLS%vsvars32.bat" 
IF  EXIST  "%VS140COMNTOOLS%"  CALL  "%VS140COMNTOOLS%vsvars32.bat" 
IF  EXIST  "%VS150COMNTOOLS%"  CALL  "%VS150COMNTOOLS%vsvars32.bat"

(update) VS 2017:

call "%vsappiddir%..\tools\vsdevcmd.bat"
pablog
  • 7
  • 1
  • 3
0

You tried to allocate a single byte array to determine how much memory you could allocate. Single arrays are limited to 2^30 elements. /LARGEADDRESSAWARE doesn't change that.

Try allocating a list of 100mb arrays.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • No, sorry. That's not the reason. Actually i was just running the application which allocates memory in various array. I tried with a test allocate in the constructor if App with various nested arrays but the same: at 1.269.472 KB is deadend. – charly_b Dec 21 '17 at 10:03
  • 1
    @charly_b: I don't know what it is then. That constant is too low for LARGEADDRESSAWARE to be the cause. I suppose it's possible you have a 32 bit machine and haven't set /3GB in the boot parameters but even so you haven't reached it yet. – Joshua Dec 21 '17 at 16:19
  • THANK YOU Joshua, you must also set the /3GB parameter for the OS! We moved from a Win7 to Win10 environment and missed this step. The LARGEADDRESSAWARE flag was set but wasn't doing anything, and it being 10 years later nobody remembered the OS flag. In Win10 it's set with the command "bcdedit.exe /set increaseuserva 3072", instead of the Win7 method using boot.ini. – Mark Apr 05 '23 at 04:29
  • @Mark: Interesting that you're still on 32 bit in 2023. – Joshua Apr 05 '23 at 13:56
0

I reopened the issue. To answer my questions completely

1) It did not work with x86. I change all projects to use 'any cpu' now. When setting up the project i had problems with some 2.0 third party lib but this seems to work now, maybe with a new framework version (4.5). so i'm able to switch to "any cpu" now.

2) It seems, only the entry assembly must be edited with editbin.

3) Project setting "32 Bit bevorzugen" must be disabled.

4) Visual Studio Host Process must be deactivated.

5) Actually for most projects it wasnt enough to just make the settings. I needed to switch on "32 bit bevorzugen", recompile, switch off again, recompile and then it magically works. seems there is some sporadic problem in the build process of VS 2012 i use..

charly_b
  • 69
  • 10