64 bit Vegas still a crasher

Comments

Sebaz wrote on 10/23/2011, 8:33 PM
The file sfs4rw.dll is described as the Sony S4RW Component that communicates with Sony's applications and, in turn, communicates with certain hardware. I'm pretty certain that you have a problem with your machine.

That was actually the first time I got that particular file error. Every other time it's been like this, including just now:

Extra Information
File: C:\Users\Sebastian\AppData\Local\Sony\Vegas Pro\11.0\gpu_video_x64.log
File: C:\Users\Sebastian\AppData\Local\Sony\Vegas Pro\11.0\dx_video_grovel_x64.log
File: C:\Users\Sebastian\AppData\Local\Sony\Vegas Pro\11.0\svfx_video_grovel_x64.log
File: C:\Users\Sebastian\AppData\Local\Sony\Vegas Pro\11.0\dx_grovel_x64.log
File: C:\Users\Sebastian\Vegas Projects\Mark Rehearsal.veg

Problem Description
Application Name: Vegas Pro
Application Version: Version 11.0 (Build 371) 64-bit
Problem: Unmanaged Exception (0xc0000005)
Fault Module: C:\Program Files\Sony\Vegas Pro 11.0\vegas110k.dll
Fault Address: 0x0000000180017594
Fault Offset: 0x0000000000017594

Fault Process Details
Process Path: C:\Program Files\Sony\Vegas Pro 11.0\vegas110.exe
Process Version: Version 11.0 (Build 371) 64-bit
Process Description: Vegas Pro
Process Image Date: 2011-09-27 (Tue Sep 27) 17:50:30
Sebaz wrote on 10/23/2011, 8:40 PM
2. Only purchase RAM qualified for your specific motherboard. If it ain't on the list then don't try (buy) it. Run faster RAM at slower timings for better performance and stability (verses the reverse). I'm running G.Skill 1600 at CAS9 currently.

Back when I built this computer, in June 2010, I remember checking for that but unfortunately there was no kit of 16 GB that was certified, so I decided to go with what was the best rated at that time, and it was far from cheap, the kit was over $600.

So my kit is supposed to be 9-9-9-24. So to try slower timings, what numbers should I set the values to in the BIOS?
John_Cline wrote on 10/23/2011, 9:53 PM
Sebaz, I'm still convinced that this a problem on your machines. First of all, I have heard of Vegas throwing in unmanaged exception error because Apple released another hosed version of Quicktime and I've also seen it because of audio drivers. When you go to "Options" > "Preferences" >" Audio Device", what choices do you have under "Audio Device Type" and which one is selected? You might try changing it to something else.
Sebaz wrote on 10/23/2011, 10:22 PM
"The HIS site makes it a pain to find the correct drivers, at least in my case. The drivers that came with the card are NOT compatible with Windows 7 32 bit or 64 bit."

I never downloaded the drivers from the HIS website. The drivers on the AMD website work just fine. However this is not a big deal when it comes to this since I had these crashes when I was using three different Nvidia cards throughout the years, always with the latest drivers available, just as now I'm using the latest AMD drivers available for the Radeon.

"A Final note: The power of an NLE like Vegas can trigger problems that other 64 bit software's will never expose. So it is safe to go 10mph with bald tires but try it at 100 mph and big problems are likely to happen!"

Maybe, but the other 64 bit software I use is also processor and memory intensive, such as After Effects CS5 and Premiere CS5. They rarely ever crash.

"Sebaz, I'm still convinced that this a problem on your machines. First of all, I have heard of Vegas throwing in unmanaged exception error because Apple released another hosed version of Quicktime and I've also seen it because of audio drivers. When you go to "Options" > "Preferences" >" Audio Device", what choices do you have under "Audio Device Type" and which one is selected? You might try changing it to something else. "

If it's my machine, then like I said, Vegas 64 is extremely picky, since no other software, 64 or 32 bit, crashes so badly for doing mundane tasks such as pressing the space bar. Not even 32 bit Vegas.

The audio device currently is the default, Microsoft Sound Mapper, but I tried to select others with different versions of Vegas and still got the crashes.

Hulk wrote on 10/23/2011, 10:40 PM
@Sebaz,

I should have been more clear in my memory configuration suggestion. Currently the i2500/2600 and other top of the line Intel CPUs have multipliers set to run at 1333 memory speeds. If you want to gain a few percentage points in building a faster system through speeding up the memory subsystem, tests show that going with faster RAM, say 1600 and keeping the lower timings 9-9-9-24 will show equal or better performance than going with 1333 at tighter timings.

If your RAM is running at spec and at the correct voltage then you *shouldn't* have a problem. Assuming that your BIOS correctly read the specs from your modules. One of the reasons motherboard manufacturers spec certain memory is that their BIOS will correctly identify and set up those specs. For exampling I'm running 1600 at 9-9-9-24 and 1.5V and when I check my CPUz those are exactly what I find.

The other reason a certain memory is specified for a certain motherboard is because they have tested those modules on that board and certify it as being stable. Now in theory if you have good RAM and it's running at manufacturers specs you should be okay. But as we all know weird things can happen and there can be conflicts. That's why I made the suggestion.

Here's what I would do if I were you.
1. Make sure the speed, timings, and voltage are set correctly in the bios. Download CPUz and have a look. You don't even need to install it. Just download, extract, and double click the exe file. No need to clog up your system with more registry entries.
2. Assuming everything with #1 is okay remove two sticks and see if there is a difference in stability when running Vegas. Things have to really be perfect to run 4x4GB sticks of RAM at high speeds.
3. Assuming no difference in stability from #1 and #2 then your RAM may have a problem, in which case you can run memtest, this is a long shot.
4. Your RAM may actually be incompatible with your motherboard. Again a long shot but possible. Try to borrow some memory sticks that are on your motherboard list if possible? I know this is a tough one. Hey buddy mind if I pull your memory for a few hours while I test my system?
5. Your RAM is fine and the Vegas instability stems from some other issue.

I would at least verify your RAM settings using CPUz and adjust if necessary. If that isn't the problem then pull two sticks and try that. The other options are longshots as I mentioned but for completeness I wanted to list everything I could think of memory related.

Also make sure all that other cr@p Vegas needs to run it up to date. Net frame work or whatever the hell else is needed. I've had that make a difference in the past stability-wise.

Finally, next time you buy/build a system or re-install Windows make sure Vegas is the first thing you load and test. Make sure it's solid before loading anything else. This way if it becomes unstable you know it was a certain installation of hardware or software that caused the problem.

I know how frustrating stability issues are. And how hard they are to track down. From the hardware side of things I am a firm believer in quality motherboard/memory/power supply. Next it's being smart about not junking up the system with garbage software.

I struggled for a year once (yes, seriously a year) with a Presonus audio interface that would produce audio glitches that wouldn't show up in the waveforms on the screen but could be heard. Presonus tried to help but to no avail. Finally I started stripping down the system and found out that my wireless internet card was causing the problem. I had to disable it when doing critical audio work. But get this, I only had that problem on that particular motherboard! Very weird. And Presonus had never heard of the problem until I notified them.

I know make sure my editing rig is hardwired to the internet...just in case.

- Mark
Sunflux wrote on 10/24/2011, 12:14 AM
My motherboard is the Intel DX58SO2, bought this past spring. I was one of the first to purchase it... and discover all the problems. I've been using Intel boards exclusively for the past decade, and I bought this one assuming it would be as solid an experience as those earlier ones.

In the end after much work it is actually rock solid, but there are very specific limitations and some quirky behavior that made it a huge pain to configure and make reliable.

For memory I bought Kingston HyperX - two kits of KHX1600C7D3K3/6GX, for 12gb total. I purchased this based once again upon years of great experiences with Kingston products, and I verified with Kingston support that the memory bought in that quantity would work as advertised with the motherboard.

This memory is supposed to work at 1600MHz CL7-7-7 @ 1.65V, and this is how it auto-configures itself if you tell the board to use XMP profiles.

The absolute best I could do is 1600MHz CL9-9-9 @ 1.51V. Even if I did 1600MHz CL-8-9-9 @ 1.8V the system would generate rounding errors within minutes of starting Prime95. I spent ages trying every different possible voltage, timing and other CPU memory controller settings possible, and it all turned out to be that the board simply can't handle 1600MHz faster than CL9.

And I consider myself lucky that I got 6 sticks working at 1600MHz at all - many people have found it impossible and have had to stick with 1333MHz.

Unfortunantly Kingston technical support was utterly and completely unhelpful on solving the issue. They even refused to provide me with correct manual timings for speeds other than the stock 1600MHz CL7 profile (for example, I wanted the full timings to one of their less expensive CL9 products). So it ended up being a huge guessing game for me.

I'm okay with the board now. It's been heavily tested and has worked for 7 months flawlessly under heavy load without a single crash - Vegas 10 64-bit is 100% stable no matter what I throw at it. But if I were buying again I would NOT purchase this board.

Oh, and as for your specific question... you're always OK to run memory at slower than the recommended timings - faster is the tricky part. And often (but not always) if you run slower, you can also lower the voltage to reduce heat output. I'm actually rather surprised that this memory is so stable at those speeds and just 1.51V, but throughout my testing voltage didn't play any part in the stability issues I was seeing.
farss wrote on 10/24/2011, 1:58 AM
"Most times it happens just from going to the previous cut and pressing play. In fact, 99% of the crashes happen as soon as hit the space bar. And it's been the same exact way since 8.1."

That is sounding a lot like a memory problem to me. 16GB of RAM is a dubious proposition without error detection and correction. That you can do the same thing in the 32 bit version of Vegas and not have a problem is what really makes me suspect RAM. You might well not have faulty RAM but the combination of 16GB of unbuffered RAM with no ECC seems to mean getting the data reliably over a full loaded buss can be a bit iffy.

I'd run Memtest for several complete cycles and see what that shakes loose first.

Relaxing your memory timings which is where you seem headed based on your posts below may very well help.

Bob.
Sebaz wrote on 10/24/2011, 10:01 AM
The problem is, the BIOS section that has all the memory settings has tons of them, and I don't know what they mean. So I'm wondering if I just touch the four that seem to be the main settings and set the memory 10-10-10-25 instead of the spec 9-9-9-24, if that will be enough to slow it down or not.
John McGrath wrote on 10/24/2011, 10:14 AM
its a graphics driver issue mate.
Sebaz wrote on 10/24/2011, 10:29 AM
its a graphics driver issue mate.

So one Radeon card, and three different Nvidia cards, all had graphics drivers issues on two computers, while no other program crashes so much? I don't think so.
Sebaz wrote on 10/24/2011, 12:00 PM
I and others build systems and they work, you build systems and they don’t.

Wow, does your head fit through the door? Patronizing people makes you look like an arrogant idiot. My stuff is good, yours is bad. What are you, five?

My systems are good enough that every other software runs without problems, in my previous Intel machine and now on my current AMD machine, with different graphics cards and components throughout the years. So it's not that the machines I built are poor quality, far from it, it's just that they may not be completely compatible with Vegas 64 bit, while they are completely compatible with every other 32 and 64 bit software, and it happily passes CPU and memory tests from Prime95 and similar software. To me it's obvious that Vegas 64 has a much more narrow list of hardware it works well with, but Sony doesn't advertise it so people think it will work fine in their systems as long as it's a Windows PC that meets the minmum requirements, but they should tell people the other requirements to be able to run it problem free. They should make a list of motherboards, memory, graphics cards, every component that will be absolutely problem free and publish that.
rmack350 wrote on 10/24/2011, 12:34 PM
I wonder if you were to visit someone with (what they think is) a stable machine if you could crash it? My guess is that you could but it'd be a good sanity check. The next best thing would be to send someone a project with media and have them go through the motions with it.

There is no doubt that your systems are crashing. It could be that those with stable systems might have simply learned not to do things that crash VP64. For instance, I have learned to wait a beat before clicking on layers in Fireworks because it often crashes the program if I do things too quickly.

Rob

Sebaz wrote on 10/24/2011, 12:47 PM
I knowwhat you mean Rob, but this is not the case. If I was working with a very complicated project, or trying to do weird things I would be willing to give it a thought, but this is a simple project that crashed even before I put a title track to it with just one title.

Oh, and lowering the RAM timings did nothing, so I put them back to default since that's what works for everything else just fine.
Steve Mann wrote on 10/24/2011, 2:41 PM
Do you remove the old drivers when you put in a new video card? It's quite possible that the program - Vegas in this case - is calling a subroutine within the driver code, and getting the Radeon version of the same call when you are running an nVidia card because it found the Radeon driver first.
Steve Mann wrote on 10/24/2011, 2:44 PM
"The next best thing would be to send someone a project with media and have them go through the motions with it."

That's been offered to Sebaz and others with chronic crashing, but I've never read that they took advantage of the offer.
farss wrote on 10/24/2011, 3:58 PM
"That's been offered to Sebaz and others with chronic crashing, but I've never read that they took advantage of the offer"

That's been done before, entire project shipped to SCS to run on their systems.
Outcome was the same, it crashed. You can read some of the dramas here and in other threads by Darren.

That's the one and only instance that I personally know of. Given the considerable sums of money invested (>$1M) in the project the level of angst is perfectly reasonable. SCS's response was 'we never thought anyone would try to do something like that with Vegas'. All I could say at the time was 'if you don't state you cannot then expect users will'.

However, that was a vastly different project and quite likely a different problem to the one Sebas is having. That movie project had over 100 tracks, all source was HDV from a Z1 and the project was being done in 32bit float. Changing from 32bit float to 8 bit Int made a massive difference.


From my own experience what Rob Mack has said above can hold very true. Us humans even without consciously knowing it are very good at risk aversion. It wouldn't surprise me in the least if Sebaz sent one of his projects to somene else they would have no problems with it and yet Sebaz sitting at their machine will get it to crash is a flash.

I'm going to propose a simple test for Sebaz to try.
He has said his problem mostly occurs when he jumps to the start of an event and hits Play. If he can modify how he does this to leave a small delay, say count to five, between when he jumps back and then hits play I'd be interested in the outcome.

Also I don't think Sebaz has mentioned if he is running his projects in 32bit float or 8 bit integer, would be interested to know this as well.

Bob.
Sebaz wrote on 10/24/2011, 4:28 PM
"That's been offered to Sebaz and others with chronic crashing, but I've never read that they took advantage of the offer"

Well, for that I would also have to take the time to put all the footage files in a data BD and then spend money shipping it to someone. I'm not so desperate to do that.

He has said his problem mostly occurs when he jumps to the start of an event and hits Play. If he can modify how he does this to leave a small delay, say count to five, between when he jumps back and then hits play I'd be interested in the outcome.

OK, Rob, but do you think counting to five each time before I have to press the space bar is an efficient way to edit? I mean, how much time would I waste when you add all the times I have to press the space bar even in one day if I have to count to five each time? There'd be no point in doing that, if Vegas 64 bit is so flaky that I have to count to five before hitting play, I will simply not use it.

Besides, I was just trying Vegas 11 to see what's new in it, but moving back to Vegas for me would mean an investment of over $400, about $250 for a decent Nvidia card and $190 for an Intensity Pro to be able to properly preview 1080i video on the TV set (and that's if Blackmagic fixed their drivers, because one year ago they crashed Vegas all the time).

Right now I edit with Edius 6, which has realtime for everything. I can pile like 4 filters on one event and it will play in full quality, full fps, without wasting time pre-rendering, and this is all thanks to my fast CPU, because it doesn't use the graphics card. And, using the HD Spark card I get perfect 1080i video on my TV set. Granted, there are a few things in which Vegas is better, especially in audio features, but for event videography, nothing is faster than Edius. So you can imagine that if Vegas 64 bit crashes on me every 10 or 15 minutes, while Edius rarely crashes on me, and it is way faster than Vegas, the choice is clear to me.
Dave Jones wrote on 10/24/2011, 4:44 PM
I had a very similar crashing issue but I have solved it.

In my case, using V11 64 bit, my system would BSOD when loading a large project using XDCAM EX footage. That is:

Vegas 11 loads fine.
Load the project and after what appears to be the project being close to, or completely loaded, it BSOD's.
Completely repeatable.
V10 works fine.

By a process of elimination, I found the problem to be one of my new Corsair 2 gig memory modules. It is so reliably repeatable and through eliminating all other hardware possibilities, I can be sure that it is this specific module (which is being returned).

I have since completed and shipped the job.

I hope this helps others.

regards,

DJ
John_Cline wrote on 10/24/2011, 5:04 PM
"Edius rarely crashes on me, and it is way faster than Vegas, the choice is clear to me."

Yes, we get it, Vegas doesn't work for you and Edius does. Why are you still here?
farss wrote on 10/24/2011, 5:20 PM
"OK, Rob, but do you think counting to five each time before I have to press the space bar is an efficient way to edit? I mean, how much time would I waste when you add all the times I have to press the space bar even in one day if I have to count to five each time? There'd be no point in doing that, if Vegas 64 bit is so flaky that I have to count to five before hitting play, I will simply not use it."

I'm not suggesting that as a viable way to continue editing, good grief man, I am not enitrely daft.
The point of the exercise is to isolate where the problem is occuring. If we can isolate the variable that's the determining factor between you having problems and others not having problems then others can try to repo your problem. If they're able to repo it then the precise requirements to cause the problem can be sent to SCS and they have something to work on towards getting the problem fixed.

For what its worth I too have a lot of respect for the people behind Edius, they seem to have less degrees of separation between their users and their engineers than Sony. I am assuming though that you've taken the time to persist with this thread because you see some benefit in getting this problem resolved either for your benefit or for the benefit of this community.

Bob.
Sebaz wrote on 10/24/2011, 6:11 PM
For what its worth I too have a lot of respect for the people behind Edius, they seem to have less degrees of separation between their users and their engineers than Sony. I am assuming though that you've taken the time to persist with this thread because you see some benefit in getting this problem resolved either for your benefit or for the benefit of this community.

Well, Grass Valley can be pretty arrogant sometimes, the kind of Apple attitude such as our stuff is the best and anyone who says otherwise is a moron, but their engineers are top notch, because even by the end of 2009 they had their Edius Neo (kind of like the consumer version of Vegas) which edited AVCHD in real time, even after adding three filters on them, and this was on my previous system, with a Quad Core 2.66 Ghz and 8 GB of RAM. Nobody else did that at the time, and then Adobe came out with CS5 bragging about real time with filters applied, but it needed an expensive Nvidia card to achieve that, and every time you would hit play, you would hear the fan in the card revving up to the maximum. By then Edius had released 5.5 with AVCHD native editing included, and then version 6 last year. Avid, even now that AVCHD is a mainstream format for consumers and professionals alike, still doesn't support AVCHD native editing.

I had been editing in Vegas since 2008 and I always loved the interface, but even using 32 bit Vegas and not suffering the crashes, it was annoying having to render even a simple crossfade to play it through without dropped frames, not to mention that adding 3 way color corrector, levels and saturation and it slowed down to a crawl. I do all that in Edius, I don't render and it plays real time, full frame size. So it doesn't take a genius to see the difference. Besides the real time playback, the editing method is a lot more efficient and almost everything is faster than Vegas, with a few exceptions.

However, I still like Vegas a lot and I would hope that some day they release a 64 bit version that is less picky and works well in every machine that is properly assembled and with quality components, because every now and then I like to edit something in Vegas, and its audio tools are second to none. But no chance I'm going to spend another $1500 buying components for a new workstation just so Vegas 64 bit works in it, when Edius and every other program works great in my current system.
rmack350 wrote on 10/24/2011, 6:53 PM
"OK, Rob, but do you think counting to five each time before I have to press the space bar is an efficient way to edit? I mean, how much time would I waste when you add all the times I have to press the space bar even in one day if I have to count to five each time? There'd be no point in doing that, if Vegas 64 bit is so flaky that I have to count to five before hitting play, I will simply not use it."

I don't know whether this was directed to Bob or me but neither one of us thinks that's a good way to work. In my case I was saying that another program had trained me to wait a "beat" before clicking in a certain part of the interface. A beat is just a kind of indefinite unit of time used in theater. I take it to mean wait just enough time to be deliberate in your next action, rather than it being a twitch response.

In any case it was an example of a program training me not to crash it, and an example of how we sometimes subtly modify the way we work with software, maybe without even realizing it.

Soooo...Vegas and Edius are two different products, of course. Edius has had a lot less consumer market focus, I think, and it probably benefits from that.

To me the idea of bad memory seems like a good route to pursue. It's entirely possible that 64-bit Vegas is doing something that other programs don't do and exposing bad memory, (or my programmer father's catch-all---a timing issue). It wouldn't surprise me if there was some sloppy memory handling going on that causes a crash more often, especially if other factors like hardware, configuration, or operator compound the problem.

You may have done this already but what about pulling all but 4GB out of your computer? Or even all but 2GB? And then maybe try a few different combinations of the DIMMs you have.

I have heard that 4GB modules are more prone to error than 2GB. (Edit: For example, when I look at lists of compatible DIMMS there are often far fewer 4GB modules than 2 GB, which I take to mean that fewer of them passed qualification.) I've also heard that the last two DIMM slots may also be more prone to timing errors. All this may just be mythology but something to consider. If you have two 2GB modules you can swap in, following your board's manual's instructions as to which slots to populate first, that might be worth trying. But by this point you've probably been through all that.

Rob
Sebaz wrote on 10/24/2011, 7:04 PM
Oh, then I got the names confused. Either way, I wouldn't see the point in counting to five since it's something I would never do in real life. A good NLE has to allow me to work as fast as I can.

I could take the time to pull out the modules and all that, but this is not so important to me to dedicate so much time to that. Besides, if like you say, Vegas 64 is doing something that other programs don't, including all the stress test programs like Prime95, and other video programs like Premiere and After Effects, or even encoding with x264, which can take hours with the CPU at 100% and never crashes, and Vegas 64 is the only thing that crashes, that makes obvious to me, the problem is in Vegas and the way it's built.

Still, like I said several posts above, sometime soon I want to do a fresh reinstall of everything, at which point I will install Vegas 64 before everything else and see what happens, and I'll report back here.

rmack350 wrote on 10/24/2011, 7:49 PM
if like you say, Vegas 64 is doing something that other programs don't,

This is just conjecture. If it were true then what I'm imagining is an addressing issue where Vegas places something in memory where it cannot be placed. For example, there's a whole range of addresses used for hardware other than memory from 4GB and down. Normally a 64-bit system (BIOS or OS, I don't know) maps RAM to skip those addresses. So if you limit your computer to just 2GB there's pretty much no way Vegas could try to use those addresses. The other addressing problem that comes to mind is a buffer overrun where some part of Vegas says "I'm going to use this chunk of memory" and then uses a bit more.

Another fanciful possibility is timing, where Vegas might write to RAM, ask "did ya get that?" and then move on without getting an answer. Kind of like keying your radio when the other guy is talking.

All these scenarios are fanciful. Any programmer worth their salt would tell you I'm making stuff up.

The thing is that if it happens to some and not others then Vegas *might* be a factor but probably not the *only* factor.

So anyway, if you're ambitious when you do another fresh install, try installing much less RAM, and taking any other hardware out of the system. Simplify the problem.

Rob Mack