When Vegas sent out the patch file for 8b it corrected the problem. In fact the files I am now having problems with in 8c, worked with 8b (with patch). Of course if I copy all my file to my Vegas 7, it works without any problems. In short

(Works)
Vegas 7
Vegas 8.b with patch

(Crashes)
Vegas 8.a, 8.b (Without patch) Vegas 8.c

"Do only the quad-core machines have problems"?
NO! When all else fails, I use an old P4 3gHz (a single-core Intel CPU) on an Intel 875 motherboard to do the rendering, but if I set it to "multithreading" in bios and then set the threads to 2 in Vegas, it often crashes. If I reset bios to no multithreading, OR set threads in Vegas to 1, all is OK - even if bios multithreading is enabled.
--------------------
A few days ago, I re-edited my 1 hr. 40 min. project. The main change was to cut out about a minute's worth of material (responding to my collaborators' recommendations). I started it rendering a Cineform Intermediate on my Q6600 on an Asus P5B, using Vegas 8b (too many new problems with 8c). It soon crashed. I rebooted, turned off all unnecessary services (again), and set rendering threads to 1 and tried again. It crashed.

Having written down the exact frame where the rendering stopped, I noticed it was the same in both cases. I opened the project and set the time display to show absolute frames, and found that the next frame, the one that stopped the rendering, included a rather large .JPG - 3992 x 2334 pixels - with a feathered mask. Even though I had successfully rendered that exact frame on this machine, I reduced the .JPG to 2000 x 1174 pixels. I tried again, with 2 rendering threads enabled, and: SUCCESS! (albeit with a little hit on the image quality of the .JPG, which zoomed in on a particular face in the photo).

Next, I wanted to render the exact same project, except with the time-code FX so that my collaborators who might not be able to set their DVD or other viewing device to display time codes could watch a version with time code and thus pinpoint any suggestions they might have. I added the TC by inserting a blank (alpha channel only) .PNG on a new top track, then using the FX button to put up the TC.

After rendering less than 1% of the project, the CPU usage dropped to near zero and the frames in the preview window stopped. I gave up, rebooted, opened a blank Vegas project, imported the Cinefore .AVI that I had just created, added the .PNG with TC FX, and rendered that using 2 threads, no problem (taking the slight generational hit on image quality due to re-compressing the .AVI).

All in all, rendering in Vegas eats up an immense amount of my time. It also ties up my main computer - re-compressing the .AVI took about the same amount of time with 2 threads as needed to create the .AVI in the first place - a little over 24 hours.
-----------------------
Incidentally, I have never seen an "access violation" error prompt. Where do you see these? Do you have Windows log these, and then look at the log? I have all such threads turned off - considering them to be unnecessary CPU threads that contribute to the problem. Just wondering what others' thoughts are on this issue. . .

I'm running Vegas Pro 8.0c (build 260) and as best I can tell my rendering chokes up whenever it hits the first jpg file I have embedded in my project. The video streams will all render fine as will the text boxes and such. But as soon as it hits the first jpg photo I have after the videos, the program will crash.

Sometimes it displays an error message and closes down, but other times it will just lock up solid and be completely unresponsive.

So someone PLEASE tell me I am just doing something wrong and this product will actually render video AND still images together into an output file. If not, then I've just thrown away a bunch of money on this software along with the Cinescore add-on with music disks.

So what product(s) is out there that is RELIABLE and can stop me from wasting my time trying to figure out workarounds for VERY basic use of the program?

Dont worry. Many of us have been right where you are at today.

I have done several projects lately and have had to fight tooth and nail to get them rendered. Here's what works for me in the end.

1.) Turn off .AVI multithreading in preferences.
2.) Drop your rendering threads to 1
3.) Go into you PC BIOS and shut off multithreading. (makes a quad look like a dual in Windows)
4.) Play with you preview RAM settings. Try 700 then 500 and 256..etc

These tricks will rendor you stuff slow,...but they should work.

So far, I have always won in the end,....but whew! It's a BIG fight sometimes.

CT

Rich, listen to Cliff. I had the same problems lately.
I set my threads to 1, lowered the RAM to 64, and disabled AVI multi threading, and voila, I was able to render a 20 minute semi complicated timeline(over 30 tracks) to blu-Ray 25mps template. It took about 4 hours, but it got the job done without crashing.

Obviously there is still something wrong with Vegas, when using Quad Cores, and I think SCS NEEDS to fix this.
I hope sooner than later, as I have been struggling with this Q6600 and V8.0 for over a year now

Ted

Hi,

I copy that. There is still something wrong with 8.0c on quad core machines. I have exactly the same problems.

Vegas chrashes more than often when working with AVCDH projects when rendering to HD BluRay format. I ´have multiple projects that just crashes the application. Rendering to DVD works fine. And 8.1 works fine. So this is specific to 8.0c, 4 cores (in use) and HD rendering.

Degrading the system to two or one core helps - every time!!!

SCS put the blaim on some "load and stay resident" sw that causes the problem, but that excuse is not a good one. Your system should not die due to that one application fills the 4 cores with work, when some other background process wants its share of the cpu bandwidth.

SCS - please FIX THIS - or at least publish officially some info about this problem and its proper workaround, because it IS a recognized problem!!!

Christian

"SCS put the blaim on some "load and stay resident" sw that causes the problem, ...."

They have?

Aside from that why don't you just revert to 8.0b?

It works fine for me but I'm not doing anything AVCHD. At the same time there's no compelling reason for me to switch to 8.0c

Bob.

Here is one reply I got from support:
"This is usually due to some other process on your computer requesting resource allocation during the time of the render. Since you have cores open for outside resource allocation, the render is not crashing when only using one core. There are a few troubleshooting steps I could recommend for this issue. First, try using three cores for the job and just leaving one open, by setting the max rendering threads to 3. As a troubleshooting step, you may also disable start up and background processes that may be requesting resource allocation on your system from time to time. End every process except for:

You could also try this and see if it helps. Somehow I feel a little disappointed when I cannot use all cores I have payd for...

Christian

Thanks for that post Christian.
I just want to add that this is not just a problem isolated to 8.0c. I have been having these issues on various projects (not all of them) since the release of 8.0 and using my Q6600.
It seems I get more crashes when my projects are more complicated, and require more resources. i.e. lots of tracks, lots of FX applied, and many JPEGs. Then going back to using 1 core seems to fix the problem
I agree, it is too bad that we cannot use the full 4 cores, as rendering using 4 cores flies when it does work.....

Ted

as I indicated above, I thought I had found a solid work-around for this problem by loading problem .VEGs into my old single-core P4 3gHz running on an Intel 875 MB. However, this past week I tried several times to render my 1-hour, 40-min. killer, without luck (I tried both with multithreading enabled in bios, and disabled; all attempts were with Vegas set to 1 thread; with firewall, antivirus, etc., disabled; both machines running Vegas 8b).

I wrote down the exact frame where rendering failed, and it always was on one or another rather large .JPG (largest dimensions of 3800 pixels up to about 4400 pixels). So I down-rezed all .JPGs to 2500 pixels on the largest dimension, except for a couple of stitched .JPGs that were about 3500 pixels x about 800 pixels (so that I could pan across them). It rendered to Cineform Intermediate, requiring about 2 days, and the downrezed .JPGs looked tolerably good.

However, for some unknown reason, one of the .M2t files was rendered with the video track lagging the audio by perhaps 30 seconds - leaving me with a totally useless render. I checked the .VEG, and it play those portions OK. I had seen that a few times in the past; I'm totally stumped.

I think I'll next try again with my quad, disabling multicores in bios (I hadn't tried that yet), plus using the down-rezed .JPGs. Maybe then? I wish I could get paid minimum wage for all the hours i've spend trying to coax Vegas to play fair.

Anything that takes two days to render is really inviting trouble and anquish. As you've had happen one little glitch and it's all for nothing.
I'd really suggest breaking your project down either by time or by tracks and then assemble the components in one master project that's not a render hog.

Bob.

"SCS put the blaim on some "load and stay resident" sw that causes the problem, but that excuse is not a good one. Your system should not die due to that one application fills the 4 cores with work, when some other background process wants its share of the cpu bandwidth."

I think Sony is on the right track with this. It's what I suggested quite some time ago and it just plain makes sense. I know the crashing because I USED to have it and now it's solid as a rock (on all 4 cores). I rarely crash anymore since I got rid of just about every load and stay resident program I could.... and that includes any kind of auto update systems for ALL software.

As I suggested before, go through ALL your hardware/software and turn off EVERYTHING that you don't absolutely need. If you have antivirus or firewall, then remove it from startup. Disable ALL services that you don't absolutely need and then give it a try again.

Once you figure out exactly what Vegas is conflicting with then you can turn everything else back on, but until then... empty EVERYTHING out that's not needed.

"It's what I suggested quite some time ago and it just plain makes sense."

Care to explain how i makes sense. It makes no sense to me, anyone who has the vaguest understanding of memory management or a few other people here. Not only doesn't it make sense, it doesn't fix the problem and in some cases it's coming close to bricking PCs.

Operating systems that implement memory management allocate memory to programs. They monitor what those programs are doing, oftenly using hardware. If a progam tries to access memory not allocated to it the OS kills the program. It's pretty simpe at the most basic level. If something tried to take memory that the OS had allocated to Vegas please explain why the OS would shut down Vegas. It'd be protecting Vegas from this mystery other progam. And yet not a single report of anytthing crashing while Vegas is running. What you're suggesting doesn't make sense, it makes no sense.
If the problem existed outside of Vegas why does it only affect the current builds? Again, what you're suggesting flies in the face of all the evidence.

Now I've nearly finished capturing 50 hours of HDV and am now starting to render it using 8.0b. Run about 20 hours of batched rendering. Unlike you, not a single crash. Yet I'm running every god aweful background task from Google, Apple, driver updaters and RAID drivers and monitors. You'd have to assume if something external to Vegas was going to cause it to crash it would have by now.

So what's the differential here, not what you keep flogging at all. It's project complexity. Because of the way Vegas works as you add more tracks and build more complex composites it needs to buffer more and more into RAM. That issue really comes to the fore with codecs that use intra frame compression. For sure dumping things other than Vegas out of RAM gives you a bit more room, despite that I'm running quite happily with only 2GB, not because I'm tight, because I know I don't need more and I know more RAM decreases system MTBF.

Even of there wasn't a single bug or conflict in any of the code running on the PC you will still hit brick walls. Every PC has finite limits on RAM. Add in a few bugs and a minor memory leak or two and things get really nasty. But you can avoid these problems. Not by killing off processes, that can be a very dangerous thing to do, Widetracks recent problems are a case in point. In the attempt to kill of things some users are deleting system files, hacking registry entries and trying anything in desperation.

What needs to be done is to manage projects better. 30 tracks of HD is a huge ask, it's easy enough to precomp tracks to reduce the demand for RAM. Converting your footage to a non intraframe codec is another big help. Users following these guidlelines are not having anything going bump in the night. If by chance some random error in RAM does cause problems the time lost is minor.

This approach has been tested, it works, and most importantly there's no risk in trying it. It will NOT fix every problem. There's always going to be the odd unlucky soul with dodgy hardware, there's still a few bugs in Vegas but you can take simple steps to manage the risks.

Bob.

"Care to explain how i makes sense. It makes no sense to me, anyone who has the vaguest understanding of memory management or a few other people here. Not only doesn't it make sense, it doesn't fix the problem and in some cases it's coming close to bricking PCs."

Bob,

We've had this debate already and I'm not going to get into it again. You don't agree and that's clear... and you are certainly entitled to your opinion. But point of fact... it has worked for me. It has worked for others... and now SCS is clearly saying it.

And my PC isn't "bricked" at all. In fact it's working better than ever. You don't need to LEAVE things shut down, you just need to shut everything down until you have a stable situation and then turn things on bit by bit until you find the offender. I'm not sure why
you're having such a tough time understanding this.

As to whether or not it is Vegas's fault or that of the offending software/hardware is anybody's guess, but that I am not debating.

And BTW... SCS has not said ANYTHING about a "memory management" problem. This particular "problem" may or may not exist.... so far it's nothing but a bunch of unconfirmed hear-say floating around the board.

"If the problem existed outside of Vegas why does it only affect the current builds?"

For me it is NOT affecting only particular builds. My crashing issues stopped IN THE MIDDLE of 8b's life span and has not happened since... even in 8c
And even if it was restricted to a particular build, that still doesn't eliminate the possibility of conflicts. Maybe they change something in vegas... maybe they didn't.

But as I said, whether or not you want to blame Vegas for the conflict.... or the offending program/hardware is up to you. I'm only telling you what worked for me and others to clear the issue.

"Unlike you, not a single crash. Yet I'm running every god aweful background task from Google,"

I can run all kinds of back ground tasks too... surf the net... yadda, yadda, with no issues. It's not that kind of conflict. My PURE GUESS is that it is a deeply routed memory resident system like the anti virus system that was affecting widetrack's machine.... or even some sound card software.

Blink, Bob,
I think you both have valid points. But I must say that Bob is hitting the nail on the head here. I have been getting crashes since the onset of 8.0. I have done numerous tests and have found out that I can render a fairly simple edit of cuts disoves and a few pictures on ALL 4 cores consistently all the way thru without issues, these are not small projects in time, but not very complex (low track count and FX) note that when I do this the 4 cores are humming at close to 100%.
When I get to a more complex project (like the one I have now) with over 30 tracks lots of FX and pictures I start to see crashing happening on a regular base using all 4 cores. What I have found is that when you take it to render using only 1 (one) core it will work every time (so far). Just last night I changed it to go render with 2 cores just to try and speed it up, and made it thru about half way and crashed, took it back to 1 core and it worked flawlessly.
If there are background programs that cause this problem, why does it not cause this problem with the simpler project noting that he cores are running at 100% for over an hour then as well.

I think the problem is related to how SCS handles multiple cores in the software. I think the software when it is working on more complicated stuff at the same time it looses itself between the 4 cores, and when you use only one core the only way to process this is to work the entire project in serial fashion through one core and has no way of getting lost. (sorry for the the simple way of putting it)

If you go back in this forum you'll see in many threads that many crashes are with people running Quad cores.

I know Blink you'll say, but I have a quaddie, and my projects do not crash. All I have to say to that is that you are not running a complex enough project to screw up your 4 cores.


Ted

Blink wrote"
you just need to shut everything down until you have a stable situation and then turn things on bit by bit until you find the offender. "

Blink, what was YOUR offender?

To be honest I have no idea. I basically reinstalled vista and NOTHING else... not even video card drivers. I shut EVERYTHING in vista that I could including windows firewall. indexing/search.... Then I installed vegas. It ran quite sluggishly because of no drivers and such... but it ran. I then slowly started re installing things I needed (video card drivers, sound card and drivers... etc and stopped to test Vegas each time.

It's to the point now where I have everything installed that I want without issues at all, so what EXACTLY it was I couldn't tell you, but I no longer run things like anti virus programs, auto updating, auto defragging... or ANY non essential auto startup programs... where as I USED to run a fair bit if this stuff.

I think it's also quite important to remember that not all crashes can be lumped into the same category and caused by the same thing. There are what seem to completely random crashes... and then there are crashes that you can form some kind of pattern to like crashing at the same point on a time line... which would logically indicate something on the time line that Vegas for one reason or another doesn't like.

The crashes I was having appeared to be COMPLETELY random... no particular frame or time line, no warning or anything. Vegas was just there one minute and gone the next

I agree, the ones that crash on the same point can generally be atributed to the media i.e. large jpeg or corrupted video. The crashes I see are completely random as well and occur at different places on the timeline. It runs perfectly past a point it crashed on before just to crash many minutes later at another point. With using one core sofar it slides by all the way to the end each and every time.
Just so you know, my box is purely for video editing and has no antivirus, updates set to off etc. etc.
I have done tests where I went in and shut down anything not needed or looked unfamiliar to me..... still managed to crash the 30+ track project

About a month ago I updated to 8c to be able to render out AVCHD from my Sony SR12 (1920x1080i). Unfortunately I immediately began to have crashes. I contacted tech support and they suggested removing all software and reinstalling, which I did, but it did not solve the problem. I have been in communication with tech support for over a month now without any news about others experiencing the same problem, which it appears is the case. I too have a quad core Q6600. Based on suggestions here I have attempted to limit RAM and threads, but haven't been successful. I have tried running in safe mode with only necessary programs running, and that has also not worked as it still crashes.

My projects are simple, as I am only running one video track, just splicing video together. Sometimes I get crashes where Vegas says it has stopped working. Sometimes I get crashes where Vegas just goes away. And other times I get crashes where a Microsoft C++ dialogue box opens. The crashes show up at random locations, although the last three crashes occurred at the same spot in the middle of a video segment with no adjustments.

I would be interested in doing intermediate format editing if it didn't result in a loss of quality and preserved the 1920x1080 PAR1 information from the SR12. I would be interested in rendering to Blu-Ray mpeg2; however, Vegas does not recognize the video to reimport for further editing.

It certainly is frustrating as I am sitting on over 30 hours of video to edit and haven't gotten any closer to a solution in over a month. I can render to any other format other than AVCHD without problems, but my intent is to preserve in best quality possible and figured that the same format and resolution was the way to go. My goal is to trim out unwanted footage while potentially making multiple generations of copies with no noticeable loss in quality.