Yes, that is the point of my post. I just installed 9.0b and it was unstable on large projects until I redid the memory hack that I had done on 9.0a. Although I am also using a 64 bit system (windows 7) and I have 8 gigs of ram. I'm not sure if this is useful in XP 32bit.

Regards, Marc

I´ve read all about this hack but don´t dare to do it yet.
If this memoryhack is so easy to do why is it not done already in the program?
There must be a reason.
I can´t understand why this wellknown and serious memory issue of Vegas isn´t solved by Vegas programmers - if its that easy.
/Aje

You make a good point Aje. The only thing I can think of is that on systems with less memory perhaps it causes instability. I'm using window 7 which is 64 bit and allows full access of my 8 gigs of ram. I would probably not try it on my XP system with 4 gigs.

@marc

interesting point because if i remember i think b3t came up with it for misbehaving 32bit systems with 4gb ram.

with my new system i haven't, touch wood, come up against any memory problems - come to that, on my old system i didn't either - but then again, i try to keep my tl vegas friendly....

leslie

Yeah, blinks hack really saved a number of people's a**es...

And talking about b3t, he's been silent for more than 2 weeks... Has he been banned, sick or on vacation ;) ??

Christian

well i for one hope he hasn't been banned. he can be quite obstreperous and opinionated, but he's also a fund of knowledge - especially with the memory hack he developed....

are we allowed to take holidays from the forum? no one told me so?

Some info to share:

The hack works, but there's still heavy limitations for 32 bit OS's.

I have a 32 bit system with 4Gb of RAM (3.25 is addressable) on XP 32 and Vegas 9.0b. I have a 12Gb swap.

The hack is supposed to allow the touched exe's and dll's address more than 2Gb - the 2Gb limitation is usually imposed for XP 32.

For my projects, Vegas rarely gets to 1Gb of mem usage during a render, and the system *always* has over 1Gb of physical memory free, and around 10Gb of swap free.

Regardless, all of my complex 1080p projects crash. I cannot output them without chopping them into <4 min pieces (which is a nightmare when its an ac3 project that needs to be reassembled).

By "crash" I mean it ceases to render, with an out of memory error.

The hack as described definately improved stability for me, but only a little. For example, if a 17 minute project was crashing reliably at the 50% mark in rendering, the hack would allow it to get to over 90% before crashing. That's great, but still a 0 result if you know what I mean.

Unfortunately, the memory issue doesn't behave in an easily measurable form - removing 25% of the project still resulted in a crash after roughly 90% of the project was rendered - some crazy memory stuff going on there.

I only started to get traction once HD source material was limited to 3:30 per VEG file. Your milage may vary.

Cheers,
Jason

Jason,
That's very helpful info, thanks. I have a very similar system right now as you do. It just confirms for me that I'm going to upgrade a bit to a 64bit OS with a lot more RAM before taking on any more large projects.

The ”2 GB Hack” is not really a Hack – it is just a way to work around a Windows memory issue that disturbs many programs – i.e. Flight simulator, FIFA Manager 09, Gothic 3 etc.

Obviously the programs are written to utilize more than 2 GB – but something goes wrong when Windows tries to allocate space over 2 GB via the page file.
The remedy for all programs is to change one single setting it the programs file header to tell Windows to allocate the space over 2 GB in another way – and this works well for Flight simulator, FIFA Manager 09, Gothic 3 and also for Vegas etc.

This is just my “2 cents” from some Googling on the topic.
Why the programs are not delivered with this setting in their file headers I can not say – but reading the specific forums for all the programs testifies that the setting seems to be harmless and and seems to solve the problem.

The 32-bit version of Vegas is delivered compiled with a 2GB limitation because this is the standard flag for the compiler, and because this is the standard practice for Win32.

Win32 allows each program 2GB of virtual space. This is a combination of RAM and Page file provided by the OS to the program. The program doesn't know the difference and treats it all as if it were RAM.

The program is in charge of asking for the memory space. Many programs will never approach 2GB of usage.

I think SCS was just being conservative with Vegas by not compiling it to be Large Address Aware (LAA). It seems like users who've changed the flag haven't had stability issues, nor have they had buffer overruns or security breaches (even if the hack is causing buffer overruns probably no one is interested in exploiting it yet).

If you alter 32-bit Vegas to be LAA you'll get much better results running it on a 64-bit OS because the OS can actually provide more RAM to Vegas. A 32-bit OS can never provide Vegas with 3GB of RAM (the OS still needs RAM and 3GB is about all you'll have available) so you'd just end up using more page file and slowing things down.

Rob Mack