For me the answer seems to be…yes!
Projects will regularly crash “Runtime Error”. Even modest projects:
7 slots HSSE
1 Reverence
Tempo track
Arranger track
If I try adding to this project in any way RAM usage reaches about 2.4GB then…Runtime Error!
I gave up attempting larger projects a few months ago.
Fortunately I have a 64bit Win7 partition where I can work these projects.
Incidentally, I get the same Runtime error when trying to work the same songs on my 32bit laptop.
/3GB switch? J-Bridge?
Waste of time? Not at all. But if I could spare a whole week of downtime to do the upgrade, i’d be right there with ya.
However, I suspect that no amount of extra memory bits will fix the broken lanes behaviour and transparent events!
Hooray for progress ? 
But apart from that, it works a treat.
Works fine here!
No probs here either. In fact I was on about 70 tracks, all with compression and reverbs of one kind or other and 3rd party EQing, before I had to start freezing tracks.
OK, seems that I’m in the minority with the Runtime errors. 
Must be something else going on to cause the crashes.
I did file a report and part of the response from Steinberg stated:
“You are using a 32-Bit operating system. In this case Cubase can address max. little bit less than 2 GB RAM!!! Reaching this limit can cause applications to crash unfortunately.”
Guess I’m doing well to reach 2.4 GBs 
Hang on, am I missing a trick here? I’m under the impression C6 x64 is a waste of time since all my VSTi’s and ReWire are only 32bit (and I can’t seem to get jbridge to work).
What am I missing?
You’re doing very well! Once my projects get to around 1,4GB mem usage, any Variaudio editing that I do is on very shaky ground, and will crash every 10 or so edits.
Here’s the rub: The application should handle low memory conditions in a controlled fashion - it shouldn’t just fall flat on it’s arse and die cos memory is low. That’s lazy programming. Getting us to upgrade our memory (and its addressing system) means the developers don’t have to improve their memory handling error code or fix the leaks so urgently - just throw more memory at the problem and it will magically “go away” (actually, the errors will be postponed until our thirst for memory hungry sample libraries takes a new turn and even 64 bits will soon be considered inadequate)
/FD 
Even with /3GB and /PAE switches, that’s indeed is normal behaviour for a 32bit OS. When I push the memory over 2.45GB I’ll get the runtime error too.
Efficient memory use in your projects is crucial on 32bit these days…
So I wondered, do you run those 7 instances in the instrument rack (multitimbral) or on instrument channels (1 patch each)?
Using it as a multitimbral could save you some memory. With HSSE’s disk streaming to “disk” it could save you around 140mb with one instance instead of seven. When the balance is more to RAM you can save up even more RAM. I Know it’s not a stunning amount, but every MB could be welcome some time 
The 7 HSSE tracks are created in 1 instance using the HSSE multi program rack in VST instruments.
Runtime error here too.
I hope next update could be more 32 bit environment friendly.
That’s the right way indeed
If your runtime error is related to the memory issues discussed here, don’t expect Steinberg to solve that. Simply because they can’t. That’s a limitation of the 32-bit memory space.
With the /3GB and /PAE switches we are squeezing the last options out of the memory mapping in a 32 bit environment. But the only real solution to expand the use of all your available memory above 4GB, is by moving to a 64 bit environment.