32 bit EXE set LARGEADDRESSAWARE

Question

0.00/5 (No votes)

See more:

.NET2.0

hi,

I have a 32 bit windows application deveoped in VS 2005 .NET 2.0 , it was failing with memory exception on reacing 1.3 GB , I enabled LARGEADDRESSAWARE flag on windows7 application worked fine till 2.1 GB .

I didnt find much info online for Windows Server 2003 SP2 standard edition .

Will the exe with flag set work or any changes required in boot.ini file to set upto max 4 GB ?

Please suggest if you have any idea / faced this issue earlier.

Thanks in Advance.

Thanks,
Shreyas

Posted 4-Oct-13 11:20am

srastogi85

Add a Solution

Comments

Ron Beyer 4-Oct-13 17:25pm

Out of curiousity, what are you doing that requires > 1gb of RAM for a single application instance?

Sergey Alexandrovich Kryukov 4-Oct-13 17:39pm

I understand your curiosity. Too often, such things result from overly simplified architecture, if not plain sloppiness.
I tried to answer. Will you check up if I remember related Windows facts correctly?
Thank you.
—SA

srastogi85 4-Oct-13 17:44pm

Sergey i debugged it through redgate memory profiler it showed memory consumed in unmanaged code , then used debugDiag to identigy libs it identify Widowscodes.dll and mscorworks.dll , so
i made app LARGEADDRESSAWARE to make it work part this file issue as otheroperations can be performed. debugDiag didnt identified leaks in code dlls , thats the issue

Sergey Alexandrovich Kryukov 4-Oct-13 17:48pm

Well, then the question is what did you do with unmanaged code and why. Please see my advice below and in my answer.
—SA

Sergey Alexandrovich Kryukov 4-Oct-13 17:43pm

OP tried to answer you, please see below, with my comment...
—SA

srastogi85 4-Oct-13 17:30pm

I have a large file of around 5lakh rows with 10 numbers in each line , I reading this file into array, then making rows of 5000 and creating inserts and saving into database, bit complex requirement, and fetching it back into DTO and showing on screen memory lost 700 MB , and CLR already uses 600 MB so we reach the limit.

Sergey Alexandrovich Kryukov 4-Oct-13 17:42pm

Chances are, you should keep most of the data on file, not all of it in memory. Your approach is over-simplified, so you pay by going out of memory. You can digest your line structure in more programmatically accessible form (binary, strings but with index table for fast access, and so on). If you want it, I can advise more on that.
—SA

Ron Beyer 4-Oct-13 17:51pm

Maybe as Sergey said you are over simplifying your explanation but it sounds to me like you should be batch processing the file instead of trying to do it in one huge chunk. To me it sounds like a simple flat file to DB operation, and I'd venture to say that you don't need to load the entire thing into an array.

nika2008 4-Oct-13 18:07pm

i am not sure what u are try to do but u can fix the memory problem by using
BackgroundWorker?
http://msdn.microsoft.com/en-us/library/cc221403(v=vs.95).aspx

Ron Beyer 4-Oct-13 18:23pm

Simply making the same code threaded will not solve a memory problem, you are just doing the same thing in a different thread...

nika2008 4-Oct-13 18:50pm

i had the same problem, my deskapp reading more then 1.3gb ram but when i use the BackgroundWorker my app max ram need was 30mb i thing is not the same think u must try it

srastogi85 11-Oct-13 14:00pm

hi,

I tried to debug the issue using Debugdiag , it showed memory leak in below libs ,

these are the dlls where leak occurs , over i period time the leak for these dlls increases , leading to application crash, Please suggest what can be done.

I am using .NET framework 2.0 and my application is 32 bit.

mscorwks.dll is responsible for 121.05 MBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:

mscorwks!EEVirtualAlloc+119: 120.69 MBytes worth of outstanding allocations.

mscorwks!DebuggerHeap::Alloc+2f: 284.07 KBytes worth of outstanding allocations. If this is unexpected, please contact the vendor of this module, Microsoft Corporation, for further assistance with this issue.

Warning WindowsCodecs.dll is responsible for 13.51 MBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:

WindowsCodecs!WPF::ProcessHeapImpl::Alloc+16: 13.43 MBytes worth of outstanding allocations.

WindowsCodecs!zcalloc+1c: 86.67 KBytes worth of outstanding allocations. Thanks,

Shreyas

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-10-04T11:37:00

As you should understand, Win32 addressable space is only 4Gb, but, on 32-bit OS versions, it is limited to only 2Gb (the rest is reserved by OS), and can be extended to 3. On 64-bit versions, a 32-bit application is executed under WoW64: http://en.wikipedia.org/wiki/WOW64[^].

In case of WoW64, your application can get up to 4Gb.

But that's not all. I'm not sure if you are calculating your memory usage correctly. (And no, you should not rely on the Task Manager.) You may count the memory you take for some data object(s) you use, but this is not all memory you need. Simply enough, if you have not enough memory, you just don't have enough. OS is not trying to full you around and hide some valuable memory under the hood. You should either think of migrating to 64-bit architectures or limit your memory consumption by refining your architecture or keeping part of data on the disk.

[EDIT]

I learned that you have been using a memory profiler later, after I posted this answer. Well, very good…

—SA