Some interesting memory observations and avchd...


montanacotton wrote on 1/23/2010, 7:50 AM
Okay, it definitely sounds like there is a solution here. Unfortunately for me, I am not a techy - and there is sooo soo much info given here and over a long course of discussion - it's confusing. Can someone sum up the steps to take clearly one by one for a 32 bit system? I am anxious to see if this fixes my system too.

I guess I should also state my specs if that helps:

Dell Vostro with Intel(R) Core(TM) 2 Quad CPU Q9650 @350Ghz with 4/0GB RAM and 500 GB hard drive. Running Vegas Movie Studio Plantinum 9.0 (but having the same problem with Adobe Premiere -which I switched to thinking vegas was the problem). Using Sony HDR-SR11 camera with HD footage, although not trying to create blue ray - just good regular DVD's.

Thanks again to all of you for your insight and time!
jasonvideodad wrote on 1/24/2010, 7:37 PM
Hey I used "blink3times"'s tip and it worked great.

First download the CFF Explorer Suite from

Then find the 6 files listed: VegasMovieStudioPE90.exe, VegasMovieStudioPE90k.dll, Sonymvd2pro_xp.dll, m2tsplug.dll, mcstdh264dec.dll, wmfplug4.dll.

Some of these are found in the FileIOPlugIns subdirectory. The Sonymvd2pro_xp.dll is found twice (once in the main directory and again under the plugins).

Change them all using the CFF explorer program. It is important to run the CFF Explorer "As Administrator" or you will not be able to save the changed file.

Each file must be opened with CFF Explorer. Click on File Header under the NT Header line item. Then click on the "click here" area in the bottom right corner of the popup box. Place a check mark in the box next to: "App can handle >2gig". Save the file and close. Reopen CFF Explorer and do this for each of the 6 above files.

This worked wonderfully for me. It saved my sanity and made me enjoy processing video again.

All thanks goes to Blink3Times for discovering/sharing this fix for the restricted memory problem.

By the way, I did create a backup of Vegas before I changed these files; but it worked, so I did not have to restore the old files.

I hope this helps.

DGates wrote on 1/24/2010, 8:19 PM
When members get booted off, their old threads and posts should go to.
ushere wrote on 1/24/2010, 8:32 PM
while i appreciate the thought, there's obviously a great many people still benefiting from b3t's revelation.

so, do you think we should lose this useful information or repost and not give due credit to the original poster?

DGates wrote on 1/24/2010, 8:44 PM
I think we should copy and paste it into someone else's thread.

DGates wrote on 1/25/2010, 10:10 AM
Besides, isn't that what most forums do when a member gets yanked?
jabloomf1230 wrote on 1/25/2010, 10:26 AM
Actually, a different poster discovered this trick. Blink later started this thread and explained it in more detail
Rob Franks wrote on 1/25/2010, 11:00 AM
Sounds like a bit of petty jealousy to me. Are we not a bit more grown up here?? Who cares what, when, why and where. If it works and people are gaining from it then why mess up the thread with this rather mature talk?
Ncottrell wrote on 1/26/2010, 6:04 AM
I cannot agree with removing this post for any reason!

I love my Vegas Movie Studio and use it quite a bit. I was thoroughly disappointed and depressed when I couldn't get it to render on my new Windows 7 64-bit computer even though Sony's website said it works with Windows 7.

What would I have done without this information? And you can't move it because I found the link to it from another forum, and others probably do also. Why put all of us through misery instead of letting us find the fix?

I contacted Sony from their support page about it and never heard back from them. I suspect that THEY don't want to be the ones telling people about this fix because they don't want to advise people to mess around in the files.

david_f_knight wrote on 2/4/2010, 12:54 PM
Here's a little background info relevant to this discussion:

The ">2GB fix" sets a standard flag in 32-bit executable files required for the application to address more than 2GB of virtual memory, up to 3GB of virtual memory. That flag is called IMAGE_FILE_LARGE_ADDRESS_AWARE.

However, not all versions of Windows enable the use of that flag, regardless of how it has been set in the executable file. See this Microsoft article:

It was last updated in 2005, before Vista and Windows 7. As far as Windows XP is concerned, it states that only Windows XP Pro can enable the use of that flag, and that its use is disabled by default. Windows XP Home Edition cannot enable the use of that flag. I don't know which versions of Vista and Windows 7 can enable the use of that flag. In any case, the way the use of that flag is enabled is with the /3GB switch in the C:/boot.ini Windows startup file, as shown in the article.

It would be helpful if people that post here telling whether or not the ">2GB fix" worked for them would also state which version of Windows they are using (32 or 64 bit; XP, Vista, or 7; Pro, Home Edition, Ultimate, etc.), as well as whether or not they have the /3GB switch set in their C:/boot.ini file. Also, stating the version of Vegas you use would be helpful.
johnmeyer wrote on 2/4/2010, 4:22 PM
whether or not they have the /3GB switch set in their C:/boot.ini file. I find this information very useful and interesting, but ultimately confusing.

I just did a little research to better understand what the /3GB switch does. I then looked at the boot.ini file on my WinXP Pro SP3 computer. As you can see, I don't have the switch:
[boot loader]
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Ah, but here's the thing:

Windows reports that I have 3GB in use!

I actually have 6GB of memory installed (for Vista, which I can boot to when I want, which as it turns out, is never).

So, it appears to me that there must be some other way, besides the 3GB boot.ini switch, to get Windows to recognize more than 2GB of application memory.
david_f_knight wrote on 2/5/2010, 10:11 AM
It is confusing because there are so many different contexts or layers involved with memory. The /3GB switch doesn't tell Windows how much physical memory to use, but how to partition the 4GB virtual memory address space that every 32-bit process has. Whether your computer has 256MB of memory or 256GB of memory, 32-bit processes always have a 4GB virtual address space. (Virtual memory is independent from physical memory, and it's actually stored on your hard disk and just copied to or from physical memory in blocks called pages by the operating system as needed.)

That 4GB virtual address space is, by default, partitioned 2GB to the user application code and its data structures, and 2GB to the operating system and its data structures. The user code cannot access the operating system code's memory partition because the CPU protects it using special operating modes. That prevents one badly behaving user program from interfering with the operating system or any other user program.

Usually, though, the operating system only needs less than 1GB of memory, so at least half of its share of the 4GB virtual address space is wasted. That's what the /3GB switch is for: it allows changing the partition of the 4GB virtual memory address space to 3GB for the user code and 1GB for the operating system code, allowing user code to access up to 3GB of virtual memory rather than just 2GB of virtual memory.

So, 32-bit Windows XP Pro knows how much physical memory is in your computer but only uses about 3.5GB of it, if you've got at least that much installed. (It needs to map some of the 4GB address space to non-main memory devices, such as to a window into the memory on your graphics card, your system BIOS (a.k.a. ROM BIOS), and certain other devices like the timer and so on, which is why it isn't using 4GB of your main physical memory.)

So even though 32-bit Windows XP Pro is using about 3.5GB of your main physical memory, it is using it across several programs, including Windows itself. But without the /3GB switch in your C:/boot.ini file, each of your user programs is limited to 2GB of virtual address space (and therefore to at most 2GB of physical memory, as well) for user code and data.

I know it's complicated, but hopefully that helps clarify things a bit.

Something I should have mentioned in my previous post: Windows only looks at the C:/boot.ini program when it is starting up. So, you have to reboot your computer before any changes made to the C:/boot.ini file will take effect. Also, be careful modifying the C:/boot.ini file, because if it cannot be interpreted due to, say, a misspelling, then Windows will not start up. If that happens, you should be able to start Windows in "safe mode" and correct the C:/boot.ini file. I don't say that to scare you, because adding the /3GB switch is very easy, but don't change anything else in the C:/boot.ini file unless you know exactly what you are doing.
Guy S. wrote on 2/5/2010, 10:53 AM
<Open the others and do the same>

Which others?

Thanks for the great find!

jabloomf1230 wrote on 2/5/2010, 11:16 AM
@david f knight,

Although your post looks elaborate, it is an excellent summary of what you have to put up with, using a 32 bit OS. I would add one other point: 32 bit Windows usually can't use the entire 4GB memory space, because some hardware devices, such as video cards, utilize memory addresses at the top end of the 4GB addressable space. You usually end up with some odd number like 3.75 GB or 3.35 GB usable, depending on your hardware. BTW, having more than 4GB of physical RAM under 32 bit Windows does you no good, as the extra RAM is just ignored. There are ways of writing 32 bit software that can access large amounts of physical RAM, but such techniques are rarely seen in commercial software.

If you go into the Windows device manager, you can see which devices are "reserving" memory addresses. You have to take this "hole" into account when you use the /3GB switch, as you can starve the OS for physical RAM and cause a lot of extraneous use of your swap file. Under 64 bit Windows, most computers have a BIOS setting that allows the OS to ignore this "memory hole".

All this "goofiness" is irrelevant under 64 bit Windows. As RAM has become cheaper and software is written to use multiple processors and more RAM, a 64 bit OS is almost mandatory.
david_f_knight wrote on 2/5/2010, 5:15 PM
To GS:

<Open the others and do the same> was referring back to the first message of this thread.
david_f_knight wrote on 2/5/2010, 7:07 PM
To jabloomf1230:

This is getting off topic, so I don't want to dwell on this, but I don't want readers to be left with the wrong impression. There are several issues at play besides the word length/number of address bits. 64-bit operating systems still use virtual memory and still have to protect operating system code and data from user code, and that's where most of the complications exist. The other issues we both pointed out are just moved from the 4GB neighborhood out to the 2^64 byte neighborhood.

It should be a long time before we start bumping up to that limit of course, but back when the first PC was designed, bumping up to the 1MB address space limit it had seemed awfully far away, too! (They were 16-bit machines with 20 address lines.) Nobody thought in terms of gigabytes of anything. I think there was just barely 1GB of memory on Earth at that time, if you added it altogether. When it was introduced in 1981, the IBM PC had 16KB of memory and, I believe, a 360KB floppy disk drive (no hard disk at all). And it cost about $8000 or so. It's entirely possible, 30 more years from now, that people will be complaining about the limited address space imposed by 64-bit operating systems and the convoluted things necessary to deal with that, and start making the transition to 128-bit operating systems. But of course, that isn't our worry today.

Incidentally, the swap file can't make up for inadequate address space, rather the swap file allows having more virtual memory than physical memory. So, if the operating system needs more than 1GB of address space, then you can't use the /3GB switch. In the case of 32-bit Windows, it should never require more than 1GB of address space, though. The Windows memory manager controls which memory pages are swapped out and when based on whatever algorithm it uses to try to maximize performance by minimizing swaps. It doesn't (usually) matter whether they are memory pages holding contents of the OS address space or memory pages holding contents of the application address space.

Also, 32-bit Windows deals as well with multiple processors as does 64-bit Windows. That doesn't have anything to do with the number of memory address lines. But as you say, when memory gets sufficiently cheap (i.e., when the cost of 4GB of memory is essentially insignificant), it will make no sense not to use a 64-bit OS. People will find more ways to make good use of massive amounts of memory, so people will have a reason to want more.
Ninan wrote on 2/6/2010, 1:23 PM
Is it the case that one of the files to which the >2gig fix should be applied (mcstdh264dec.dll) is absent from VMS?

As I am technically dumb, I wouldn't like to overlook sth or to mess around. On the other hand, I am absolutely fed up with the rendering crashes and decided to try the blink3times fix.
david_f_knight wrote on 2/6/2010, 2:07 PM
Here's an update to the post I made on 2/4/10:

I found another Microsoft article that is more recent (2009) than the previous Microsoft article (2005) I cited. It contradicts one aspect of the previous article (re: Windows XP Home Edition), and provides more information for all versions of Windows. Here it is:

Significant points (regarding home-type versions of Windows):

1) Windows Vista and Windows 7 don't have boot.ini files. It has been replaced by something called BCD (Boot Configuration Data) in those versions of Windows.

2) Windows Vista and Windows 7 don't have a /3GB switch in the BCD. They use the IncreaseUserVA element in BCDEdit instead, but only for 32-bit versions of these OS. (BCDEdit is the BCD editor.)

3) The /3GB switch works with all 32-bit versions of Windows XP, not just 32-bit Windows XP Professional. (I haven't tested this, and this contradicts the older Microsoft article.)

4) The article claims that the /3GB switch in Windows XP cannot be used with drivers of certain vendors' products, especially for some video graphics drivers, because they require the OS have more than 1GB of address space. [However, I believe the system BIOS controls the size of the window into graphics memory and that the OS never sees it in a flat address mode, but just what is within the window. If so, this should allow fitting the entire OS into a 1GB address space allowing the use of the /3GB switch as long as the video memory window size is small enough.]

5) For 64-bit versions of Windows, there is no need to set either a /3GB switch or a IncreaseUserVA element in the boot up control file. The size of the user-mode virtual address space of 32-bit applications on 64-bit operating systems is 2GB unless the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is set in the executable, in which case the virtual address space is 4GB.
david_f_knight wrote on 2/6/2010, 3:13 PM
To Ninan:

I have VMS Platinum 9.0b, and the file mcstdh264dec.dll I have exists in the directory C:\Program Files\Sony\Vegas Movie Studio Platinum 9.0\FileIO Plug-Ins\m2tsplug on my computer. Did you look in that directory?
Ninan wrote on 2/6/2010, 3:25 PM
Thanks. I found it.

edit. GREAT, the fix has really helped! How unclever of me to have waited so long with its impementation. THANK YOU blink3times! THANK YOU david_f_knight, without your assistance I would've certainly given up.
BillyfromConsett wrote on 2/13/2010, 2:49 AM
1st Post - I hope I've got this right.
Will the blink3times fix using the altering of the 5 files reduce crashing during renders of AVCHD projects using Windows 7 64bit? This being applied for Vegas Movie Studio 9 Platinum.

I notice that Sony hasn't released a patch for this app for well over a year, so I take it that for some reason Sony have not supported this fix?
david_f_knight wrote on 2/13/2010, 10:45 AM
The blink3times mods *might* reduce/eliminate crashing during renders of AVCHD projects using any 64-bit version of Windows, including Windows 7, for both Vegas Pro 8 (I don't know about v. 9), and Vegas Movie Studio Platinum 9 (I don't know about v. 8). My contribution was to recognize that 32-bit versions of Windows require an additional change, to the Windows boot configuration file (C:/boot.ini for Windows XP, or the BCD store for Vista and Windows 7).

There is no guarantee. The only way to know if it will work for you is to try it out and see. The changes themselves are very tiny, and can easily be undone if they don't help you. However, as far as I know, the changes have not introduced any new problems.

Sony does not support this fix; blink3times and I are not Sony employees, we are customers. (This isn't really a fix, because the error is indicative of a memory allocation failure that Vegas ignores, which causes the crash after Vegas proceeds as though there were no problem. Changing the allocation of the virtual address space (what the modifications do) doesn't fix the fundamental bug, it just changes the environment so that it doesn't seem to occur with most or all projects so far. Sony still needs to fix the underlying problem by changing the program code. The blink3times mods do not change the program code at all, just the configuration of the environment it is loaded into.)
BillyfromConsett wrote on 2/14/2010, 1:45 PM
Thanks for your quick reply. Your note has helped me. I have noticed that Sony do an HD version of the app for about £30 (it's cheap) but we've already bought the app that I'll try to make work.

cheers Billy
GomerPyle wrote on 2/23/2010, 12:55 PM
I had hoped that this would solve my trimmer problems... but unfortunately no. AVCHD files played in the trimmer for a few minutes will always crash Vegas 9.0b (movie studio platinum I should add) on my machine.

Windows 7 x64 Home Premium
AMD Phenom 9550 Quad Core
8GB memory
AT RADEON 4850 512MB