Crash on render, still

Widetrack wrote on 9/19/2008, 11:34 AM
I'm continuing to experience V 8.0 crashing during a render of a 34-minute nested project. It has crashed as I try to render to either .AVI or .MP2, at several different points in the project, all later than 60%. The last 2 were at 74% and about 89%. I pulled one of my 2 1GB RAM sticks to see how to match it, and have ordered 2 more GB (@ $17 from kingston!!!)

So when I put the stick back, I switched the slots where the 2 sticks were installed. that was right after the 74% crash and before the 89% crash.

Whatever that tells me.

Anyway, i went back and made sure each project had no missing or zero-use-count files and rendered a couple of .mov files to avi, but no soap.

I've taken to rendering half the project at a time and downloading an MPEG joiner shareware. this will probably work for now, since I' only rendering Betas, bu soon (I hope) I'll be ready to render the whole final project for DVD. I'd hate to have to join 2 files for a commercial DVD--Can't imagine the gremlins that could throw into the pot.

I put the crash details below. Can anyone help?

Sony Vegas Pro 8.0
Version 8.0b (Build 217)
Exception 0xC0000005 (access violation) READ:0x93100062 IP:0x93100062
Thread: ProgMan ID=0xD58 Stack=0x339E000-0x33A0000
Registers:
EAX=0339edb8 CS=001b EIP=93100062 EFLGS=00010202
EBX=09e9eef0 SS=0023 ESP=0339ed64 EBP=0339f350
ECX=009e00e6 DS=0023 ESI=11475b20 FS=003b
EDX=93100062 ES=0023 EDI=00000000 GS=0000
Bytes at CS:EIP:
93100062: .. .. .. .. .. .. .. .. ........
9310006A: .. .. .. .. .. .. .. .. ........
Stack Dump:
0339ED64: 0074C7EB 00400000 + 34C7EB (vegas80.exe)
0339ED68: 11475B20 108B0000 + BC5B20
0339ED6C: 0339EE60 032A0000 + FEE60
0339ED70: FFFFFFFF
0339ED74: 1AD2BCB0 1A440000 + 8EBCB0
0339ED78: 006CFB54 00400000 + 2CFB54 (vegas80.exe)
0339ED7C: 0339EDB8 032A0000 + FEDB8
0339ED80: 110B0D08 108B0000 + 800D08
0339ED84: 1AD2BCA0 1A440000 + 8EBCA0
0339ED88: 4E606643
0339ED8C: 00000000
0339ED90: 0000F03F
0339ED94: 1AD37E4C 1A440000 + 8F7E4C
0339ED98: 000002D0
0339ED9C: 000001E0
0339EDA0: 12953338 128B0000 + A3338
> 0339EDF8: 364D9365 36340000 + 199365 (sfmarket2.dll)
> 0339EE38: 364D9365 36340000 + 199365 (sfmarket2.dll)
> 0339EED4: 011ADBB2 01150000 + 5DBB2 (vegas80k.dll)
0339EED8: 0339F040 032A0000 + FF040
0339EEDC: 0339EEE0 032A0000 + FEEE0
0339EEE0: 00000000
0339EEE4: 3FF00000
> 0339EF58: 7C91925D 7C900000 + 1925D (ntdll.dll)
> 0339EF5C: 7C9192EF 7C900000 + 192EF (ntdll.dll)
> 0339EFF0: 006CE40F 00400000 + 2CE40F (vegas80.exe)
0339EFF4: 0339F244 032A0000 + FF244
0339EFF8: 02F6EF00 02DF0000 + 17EF00
0339EFFC: 0339F040 032A0000 + FF040
0339F000: 1AE02B48 1A440000 + 9C2B48
> 0339F040: 7C8346F0 7C800000 + 346F0 (kernel32.dll)
> 0339F06C: 7C83473A 7C800000 + 3473A (kernel32.dll)
> 0339F08C: 7C936EB3 7C900000 + 36EB3 (ntdll.dll)
> 0339F090: 7C936F08 7C900000 + 36F08 (ntdll.dll)
> 0339F09C: 7C93770D 7C900000 + 3770D (ntdll.dll)
> 0339F0B8: 7C936EB3 7C900000 + 36EB3 (ntdll.dll)
> 0339F0C4: 7C937233 7C900000 + 37233 (ntdll.dll)
> 0339F0C8: 7C936F08 7C900000 + 36F08 (ntdll.dll)
> 0339F0DC: 7C937129 7C900000 + 37129 (ntdll.dll)
> 0339F0E8: 003B0003 00370000 + 40003 (sfwbdmux.dll)
> 0339F0EC: 7C936F08 7C900000 + 36F08 (ntdll.dll)
0339F0F0: 0000C248
0339F0F4: 1AD2BCA0 1A440000 + 8EBCA0
0339F0F8: 1A60C770 1A440000 + 1CC770
> 0339F118: 003B0003 00370000 + 40003 (sfwbdmux.dll)
- - -
0339FFF0: 00000000
0339FFF4: 005258F0 00400000 + 1258F0 (vegas80.exe)
0339FFF8: 00ADA678 00400000 + 6DA678 (vegas80.exe)
0339FFFC: 00000000



Comments

LReavis wrote on 9/19/2008, 6:08 PM
I just spent most of my week trying to render a long (1 hr., 41 min) project with a half-dozen video tracks and countless stills, M2ts, almost all with various fx & masks, etc. A real nightmare of a project. Anyway, I re-read pretty much everything that has been posted on this forum for the last several years, and I finally got an intact render (to cineform intermediate). Here's how:

1. Replaced one huge .PNG still. Even though it didn't give me a red screen or crash whenever I adjusted the pan across it, still I noticed that my first several attemps to render stopped exactly at the same place - just a half-dozen or so frames before the large .PNG. I realized that the .M2t that faded into the .PNG must have had a GOP that extended into the .PNG and the size of the still was a problem. I down-rezed the .PNG, put it on the timeline, and accepted the small hit on resolution. The next render went well past that point before crashing.

2. Pulled the 3 tiny .MOV files off the timeline and rendered each to Cineform .AVIs individually, then replaced them with the new .AVIs. That seemed to help.

3. Turned off all anti-virus, firewall, and other protection, along with my automatic back-up program (Second Copy 7). That cut the number of processes shown in the performance tab of Windows Task Manager from 44 to 40, but didn't seem to make much improvement in length of rendering before the frame counter stopped advancing; but I kept the killed for all subsequent efforts on this machine.

4. Went to View in Vegas and uncheck the "waveforms and frames" item. That seemed to help a lot, but still could not get past about 40% of the render.

5. Tinkered with "disable multicore render" (even though I have a Q6600 on an Asus P5B motherboard, 4 GB RAM, OC'd to 3.05 gHz, the great heatsink/fan that keeps CPU very cool); and played with RAM preview MB in the Video tab of Preferences, but couldn't find much payoff for my effort.

6. I had read several posts claiming that Intel chips on Intel boards are more stable, and someone else mentioned single-core machines as being more stable. So I fired up my old 3gHz P4 on an Intel 875 (the series that preceeds the currently favored 975 series) and installed Vegas 8b (having already given up on 8c because of numerous additional glitches). After copying all my files over to a pair of 1 TB disks, with one mounted as a folder inside the other and both using USB2 interface devices, I tried a render. No luck.

Even though that P4 was set in bios to allow multithreading, I put a checkmark in the Vegas Preferences box for "Disable multi-processor AVI rendering," and set the number of rendering threads (in the Video tab of Preferences) to 1. This greatly improved the length of render before a crash, but still wasn't enough.

However, after turning off all background processes AND, more importantly, again removing the checkmark from the "waveforms and frames," SUCCESS!

I also did a few other tricks that may or may not have been important, like setting up a rather large fan to blow hard on both the CPU & memory sticks after removing the side panel (it certainly did reduce the speed of the temperature-dependent CPU fan).

I hate to say it, but maybe the only solution is to use an Intel board - perhaps you can find an old P4 on ebay for cheap and use it only for rendering (that's my plan for the future). Alas, you'll won't get speedy renders - my render took about 2 days. But at least now I can sleep at night instead of mulling over my options . . .
Widetrack wrote on 9/19/2008, 8:24 PM
holy crap.

what a hellish story. but I'm really impressed at how carefully you documented your efforts. I'll bet you do sleep better now.

Please allow me to ask a few questions:

1. Why did you render the .MOVs to cineform AVI, as opposed to plain AVIs? I know nothing about Cineform.

2. how do I turn off all background processes? I've often looked at all the junk going on in the Task manager, not having the faintest idea what most of them do, but not knowing which I could turn off without inviting disaster. what's the trick?

I also have an Asus mobo and a core 2duo. I have 2GB ram and seemingly enough internal disk space.

I have an odd business model, so I only turn out a new product every couple of years. The worst part about that is that I forget all the tricks I learned in the previous project, and by then all the software's different anyway. But I recall on my last project I had the same kind of problem on a machine at least four years older than my current one, and finally had to render several mpeg-2 files and join them with a shareware I can no longer find online. The one I did find--MPEG Joiner--looked at the 2 mpeg 2s I rendered and said they were "incompatible."

so if you would be kind enough to clarify the points above, I'll get started, again.

Best wishes,

WT



Derm wrote on 9/20/2008, 1:35 AM
These episodes sound like the massive frustration that Ive experienced trying to render a large Vegas project for the last 3 weeks. I was temporarilly encouraged when I read about the MPEG joiner as I though that it might do it for me. Basically I get partial renders to any format and continuous crashing, every 5 minutes or so. I have tried so many work arounds to beat this but nothing successful. LReavis, I can feel your pain trying all of those options, I know what its like. All I know for sure is Vegas wont render PSD files for me, it has in the past, and it doesn't like jpegs that arent in RGB colour mode. Unfortunately removing the PSDs from this project is not an option.
I have many crash reports and when I tried to send them to Sony I got an error message that the post did not go through. I'd had enough at that stage. I will try to send them again.
Derm

P.S. I uninstalled AV, closed every other program, application etc.
My PC is a pentium core 2 duo. Tried this project in 8b & 8c
Widetrack wrote on 9/20/2008, 8:03 AM
This time it worked, thanks mostly to LReavis's suggestions. Here's what I did:

1. Found three more small .MOVs that I’d missed, rendered tham as plain .AVIs and replaced the MOVs with the AVIs. (Replacement wasn’t smooth, though. Found very odd aspect ratios in Pan/Crop that needed fixing, Track motion keyframes were also mucky.)

2. Although I’d already set Dynamic RAM allocation to some very low figure, when I looked again, it was back up to the 684 I usually set it to for editing, so I set it back to 64, then double-checked that it stuck on restart.

3. The idea of not using both cores after all the expense of getting them made me want to chew nails, but I checked the Preferences box for "Disable multi-processor AVI rendering," anyway and set the number of rendering threads in the Preferences Video tab to 2.

4. Unchecked "waveforms and frames" in View.

Rendering a 33-minute program to MPEG-2 took over eight hours, but it did render completely.

Can't say I'm feeling great about this late success, given the ordeals and disruptions to our businesses that these problems have caused. There are several people pretty upset at me for the delivery I was supposed to make last Tuesday when I was expecting a "mature" version 8.0b Vegas to render when asked. This is not a pretty situation.

Thanks again to LReavis and all others who've offered suggestions, and best of luck to Derm. Please let me know how it goes for you.



LReavis wrote on 9/20/2008, 1:11 PM
Sidetrack - I'm so glad to hear of your success. Still, you may find that longer projects require even more tweaking. A few years ago when CPUs were not nearly as fast and RAM was measured in MB rather than GB, it was routine to turn off a wide variety of background processes. For example, by setting visual effects to minimum (Start>Settings>Control Panel>System>Advanced>Performance Settings>Visual Effects Tab>Adjust for best performance). Once a vendor of hardware published a list of 25 such tweaks, and I usually do a few of them even now when I put together a new computer.

However, I no longer find that I get much payoff from the exercise, probably because the hardware in modern machines is so much more robust. Even turning off the anti-virus and other protection (by right-clicking on their icons on the taskbar), and turning off the automatic backup software (Second Copy, again by right-clicking) - none of this seemed to yield much payoff in my experimenting last week. And some involve editing the registry and shouldn't be done without knowing how to first back it up. Others involve processes that I no longer am willing to live without, such as automatic updates.

Incidentally, I once did disable the multi-CPU rendering on my Q6600 and setting rendering threads to 1 or 2, but that was not enough to get to the end of the render without a crash. By watching the PF Usage window in Windows Task Manager (simultaneously hold Ctrl-Alt-Del), I could pretty much predict a crash once the figure got near 2GB (the figure slowly increases during render on most of my projects, but does sometimes drop after reaching a plateau). Surprisingly, my Q6600 has 4GB RAM (only part of which WinXP 32bit can use), whereas my P4 only has 2 GB RAM; apparently that's enough.

Bottom line: I hope you've hit on a permanent solution; but maybe keep an eye on old computers on ebay with good P4 CPUs that are on Intel motherboards.

Widetrack wrote on 9/20/2008, 3:20 PM
"Sidetrack". I like that. It quite aptly describes most of my mental processes these days.

appreciate your last comments, too.

Regarding Page files: Don't they refer to data written to disk to supplement insufficient RAM? If so, it would seem that insufficient disk space or slow disk performance would be the limiting factor here, rather than low RAM. And now that you mentioned it, I'm remembering that on my last major project, I wound up watching for page files getting full as well. I'm going to have to dig back into my old files to see how that was resolved, though I think I was able to render 2 or more smaller files and join the,)

BTW, I can't find anything named "second copy" on my system. Is it included in Windows?

Thanks again for the help.

Sidetracked....

...again.
xberk wrote on 9/20/2008, 3:52 PM
Generally, in my experience, renders crash because of some media on the timeline that Vegas cannot handle .. I narrow things down and locate the media and then all is well --- but if you are sure it's nothing like that .. then ...

Just a guess but --
> 0339EDF8: 364D9365 36340000 + 199365 (sfmarket2.dll)

sfmarket2.dll is from Sonic Foundry...I don't have it on my system as part of Vegas.
It may have been part of Vegas at one time ??
If you can track down ALL the dll's in the crash log, de-install and re-install that software ..might do it....

Paul B .. PCI Express Video Card: EVGA VCX 10G-P5-3885-KL GeForce RTX 3080 XC3 ULTRA ,,  Intel Core i9-11900K Desktop Processor ,,  MSI Z590-A PRO Desktop Motherboard LGA-1200 ,, 64GB (2X32GB) XPG GAMMIX D45 DDR4 3200MHz 288-Pin SDRAM PC4-25600 Memory .. Seasonic Power Supply SSR-1000FX Focus Plus 1000W ,, Arctic Liquid Freezer II – 360MM .. Fractal Design case ,, Samsung Solid State Drive MZ-V8P1T0B/AM 980 PRO 1TB PCI Express 4 NVMe M.2 ,, Wundiws 10 .. Vegas Pro 19 Edit

LReavis wrote on 9/20/2008, 10:04 PM
yes, page file is for data written to disk that otherwise would be written to RAM. I set up my PF on a pair of quite fast striped (RAID-0) 750 GB disks, and in order to prevent fragmentation, I set the min. and max. size to be the same. In general, it is recommended that the size should be about 1.5 times the size of the RAM. So, for my 4GB of RAM, I have mine set for 6000 MB. I've also tried PF set on a fast single-750 GB disk, with no improvement in the crash problem.

In order to change the setting, go to Settings>Control Panel>System>Advanced>Performance Options>Advanced>Virtual memory>Change. Drive C: will be highlighted in the Drive window, by default. Click No paging file. Then highlight the drive where you'd like the PF, click Custom size, and set the Initial size to 1.5 times your RAM size, and do the same for Maximum size. Then click OK. Observing that PF Usage in Task Manager never approaches 3GB, there probably is no need to set it as large as I have it . . .

After you close out that window, it's also a good idea to checkmark the Background services under Processor scheduling on the Performance Options page (still in the Advanced tab). You'll get better rendering performance than if you checkmark the Programs box.

However, I think the next options regarding Memory usage is best left on Programs; but I haven't personally verified this.
-----------------------
Regarding Second Copy, it's a highly rated backup program that's pretty inexpensive. I've used it a year or so and I like it a lot.
-----------------------
A few other tips that might be useful (even though these have appeared many times on this forum and therefore are quite redundant):

1. Turn off indexing on all drives by right-clicking the drive in Windows Explorer and clicking Properties. Then clear the Allow Indexing Service . . . box. Indexing does little for improving the file search performance, and mucks up disk performance - not to mention adding another process to further burden the CPU.

In my case, I installed XYPlorer, an inexpensive file viewer. It finds files much faster than Windows Explorer, and has too many other advantages to list here.

If I want an even faster search, I open the free VunetFind2. By some unimagineable quirk, I could open files that it found just by double clicking them (it's not supposed to be able to do this). After perhaps a year, I could only open .html & .Jpg files; soon thereafter it then stopped opening any files by double clicking (computers have a mind of their own - never doubt it). So now I mostly rely upon XYPlorer.

2. Check all your RAM with MemTest. It's free, and easy to make a bootdisk for it, and running it is totally painless (google will get you all you need to know). Let it run overnight and note the errors: there must be NONE. When I first set up my Q6600 machine, it worked fine. Nevertheless, MemTest reported errors. I switched memory sticks in and out until I found the culprit, and Corsair replaced it for free. Last week I ran MemTest again when I was trouble-shooting the render problem, and still no errors; but errors can develop - perhaps because of dissimilar metals between the chip contacts and the connection they are inserted into (although I believe that gold plated contacts now have become the industry standard both for motherboards and for the chips; but I can't say for sure).

3. Once you get you system tweaked to your satisfaction, make an image of Drive C. After trying various commercial programs - occasionally with disastrous results - I switched to the free BartPE boot system with DriveImageXML installed on it. It'll take you perhaps up to an hour to read the instructions and create a bootable disk, but it's worth it. It will create an image from within Windows, but it's a much more reliable procedure to slip in the boot disk and run (also free) DriveImageXML from the Windows environment that runs from the BartPE boot disk, not from Drive C. I've restored my Drive C many times with the BartPE/DriveImageXML disk, and I've never had one failure. It's a beautiful, free, rock-solid solution that is pretty fast.
---------------------
Regarding .PSD files: Are you sure that replacing them isn't an option? I've had to do that with .TIFF files, and found that it's easy to convert formats with Photoshop's batch conversion option. Unless they are spread out over too many folders for this to be practical, you can simply let PS automatically convert them all to .PNGs; then remove all the .PSDs to a new folder. When you next open Vegas, you get a prompt asking for a replacement file for each. Seems to me there's even a way to change them with a script or with some other clever time-saver; search the forum - I remember this being discussed in a previous thread.
----------------
Later edit: I just happened to notice an Intel D875PBZ, the exact same motherboard that gave me the successful render, for cheap:

http://shop.ebay.com/items/_W0QQ_fromZR46?_nkw=intel+875&_sacat=0&_fromfsb=&_trksid=m270.l1313&_odkw=intel+motherboard&_osacat=0
MTuggy wrote on 9/21/2008, 8:15 AM
Is pre-rendering the simple solution?

I was routinely having crashes in HD projects (even 5-7 minute projects!) but found they always were occuring with jpeg's that were not resized. I would watch the task process and see that the vegas.exe file was consuming more and more RAM then it would lock up.

So, I have reverted to pre-rendering to AVI intermediates any segments with still images (too lazy to go back and resize and re-edit these older projects) and so far, it renders completely without crashing.

I haven't tried this on a full sized project to see if it fixes the issue for longer renders but I am curious if anyone else has. Also, I only had trouble with HD renders (either 1280x720 or 1440,1080 outputs), not standard DV output files.

I did try many of the solutions you Reavis did (except the waveform thing - that sounds promising) to no avail. We'll see what the trick really is.

Mike
markymarkNY wrote on 9/21/2008, 5:07 PM
I have just finished struggling with my first long AVCHD project. After several freezes, I have changed some things and so far so good.

One thing was not to overlap any .m2ts files, whether it be a simple transition, masking, etc.

Once I did that, I had no problems whatsoever with rendering the .m2ts files. I still encountered problems wherever there were .jpeg stills. I just removed them and no problems.

I will try what a previous poster suggested, which is to render .jpeg first to .avi and then stick those into the timeline.

Obviously we should not have to perform these workaround tricks but I love how easily Vegas works with editing so I will cope for now until I get a more powerful computer.
Widetrack wrote on 9/25/2008, 10:02 PM
I had the temerity to uncheck “disable multiprocessor rendering” after the last (successful) render took eight hours to render a earlier versioon of the 34-minute project with it checked. Did all the other stuff, was watching task Manager. CPU use was holding steady at about 57%; Page file steady at ~ 1.15 GB, and at 45%, it just stopped.

Just bought 2 more GB RAM that I’ll install after I sleep for a while. Hoping they won’t cause more trouble than they’re worth (but at 17 bucks a GB, that’d be hard to do).

This make sense to anyone?

Sony Vegas Pro 8.0
Version 8.0b (Build 217)
Exception 0xC0000005 (access violation) READ:0x0 IP:0x0
In Module 'vegas80.exe' at Address 0x0 + 0x0
Thread: ProgMan ID=0xA8C Stack=0x339C000-0x33A0000
Registers:
EAX=0339ce78 CS=001b EIP=00000000 EFLGS=00010202
EBX=09e70940 SS=0023 ESP=0339ce24 EBP=0339d410
ECX=009e030d DS=0023 ESI=101c86c8 FS=003b
EDX=00000000 ES=0023 EDI=00000000 GS=0000
Bytes at CS:EIP:
00000000: .. .. .. .. .. .. .. .. ........
00000008: .. .. .. .. .. .. .. .. ........
Stack Dump:
0339CE24: 0074C7EB 00400000 + 34C7EB (vegas80.exe)
0339CE28: 101C86C8 100B0000 + 1186C8
0339CE2C: 0339CF20 032A0000 + FCF20
0339CE30: FFFFFFFF
0339CE34: 1B7A00C0 19E80000 + 19200C0
0339CE38: 006CFB54 00400000 + 2CFB54 (vegas80.exe)
0339CE3C: 0339CE78 032A0000 + FCE78
0339CE40: 0BEA3D50 0B710000 + 793D50
0339CE44: 1B7A00B0 19E80000 + 19200B0
0339CE48: 53F24803
0339CE4C: 949FA8B1
0339CE50: 6D6E6E6D
0339CE54: 6E6D6D6D
0339CE58: 85868686
0339CE5C: 87868685
0339CE60: 8282848B
> 0339CE74: 7B7A7A79 7AFD0000 + 7D7A79 (System.Windows.Forms.ni.dll)
> 0339CE90: 7B7B7C7C 7AFD0000 + 7E7C7C (System.Windows.Forms.ni.dll)
> 0339CEF8: 364D9365 36340000 + 199365 (sfmarket2.dll)
> 0339CF54: 79787674 790C0000 + 6C7674 (mscorlib.ni.dll)
> 0339D018: 7C91925D 7C900000 + 1925D (ntdll.dll)
> 0339D01C: 7C9192EF 7C900000 + 192EF (ntdll.dll)
> 0339D15C: 7C93770D 7C900000 + 3770D (ntdll.dll)
> 0339D178: 7C936EB3 7C900000 + 36EB3 (ntdll.dll)
> 0339D184: 7C937233 7C900000 + 37233 (ntdll.dll)
> 0339D188: 7C936F08 7C900000 + 36F08 (ntdll.dll)
> 0339D19C: 7C937129 7C900000 + 37129 (ntdll.dll)
> 0339D1A8: 003B0003 00370000 + 40003 (sfwbdmux.dll)
> 0339D1AC: 7C936F08 7C900000 + 36F08 (ntdll.dll)
0339D1B0: 0000C248
0339D1B4: 1B7A00B0 19E80000 + 19200B0
0339D1B8: 1107E028 100B0000 + FCE028
> 0339D1D8: 003B0003 00370000 + 40003 (sfwbdmux.dll)
0339D1DC: 1B7A00A8 19E80000 + 19200A8
0339D1E0: 000001C0
0339D1E4: 1B7A00A8 19E80000 + 19200A8
0339D1E8: 1B7A00B0 19E80000 + 19200B0
> 0339D1EC: 7C97D80C 7C900000 + 7D80C (ntdll.dll)
> 0339D204: 00647E18 00400000 + 247E18 (vegas80.exe)
0339D208: 00000000
0339D20C: 00000000
0339D210: 7FD37ED3
0339D214: 00238680 00140000 + F8680
> 0339D230: 7C90E900 7C900000 + E900 (ntdll.dll)
> 0339D234: 7C9192F8 7C900000 + 192F8 (ntdll.dll)
> 0339D23C: 7C9192EF 7C900000 + 192EF (ntdll.dll)
> 0339D240: 7C918F01 7C900000 + 18F01 (ntdll.dll)
> 0339D24C: 7C9101BB 7C900000 + 101BB (ntdll.dll)
> 0339D258: 7C8850E0 7C800000 + 850E0 (kernel32.dll)
> 0339D264: 7C90E900 7C900000 + E900 (ntdll.dll)
> 0339D268: 7C936F10 7C900000 + 36F10 (ntdll.dll)
> 0339D270: 7C936F08 7C900000 + 36F08 (ntdll.dll)
> 0339D274: 7C9101BB 7C900000 + 101BB (ntdll.dll)
> 0339D3E0: 01226512 01150000 + D6512 (vegas80k.dll)
- - -
0339FFF0: 00000000
0339FFF4: 005258F0 00400000 + 1258F0 (vegas80.exe)
0339FFF8: 00ADA678 00400000 + 6DA678 (vegas80.exe)
0339FFFC: 00000000

Widetrack wrote on 9/26/2008, 7:27 AM
…And again this morning, with all the settings in place that allowed a completed render a week ago. Before trying these last 2 renders, I swapped the slots my RAM sticks are in.

The 81% completion point is about the same crash point as in earlier attempts using both cores.

I also realized that the preference is for “AVI renders”. Does that affect MPEG renders in any way?
>>>>>>>>>>>>>>>>>>>>

Sony Vegas Pro 8.0
Version 8.0b (Build 217)
Exception 0xC0000096 (privileged instruction) IP:0x7CBCF548
In Module 'SHELL32.dll' at Address 0x7C9C0000 + 0x20F548
Thread: ProgMan ID=0xA70 Stack=0x339C000-0x33A0000
Registers:
EAX=0339ce78 CS=001b EIP=7cbcf548 EFLGS=00010a96
EBX=09e6fef0 SS=0023 ESP=0339ce24 EBP=0339d410
ECX=009effff DS=0023 ESI=021eeec0 FS=003b
EDX=7cbc1000 ES=0023 EDI=00000000 GS=0000
Bytes at CS:EIP:
7CBCF548: 6F D0 00 00 00 00 00 00 o.......
7CBCF550: 00 00 00 00 00 00 00 00 ........
Stack Dump:
0339CE24: 0074C7EB 00400000 + 34C7EB (vegas80.exe)
0339CE28: 021EEEC0 021B0000 + 3EEC0
0339CE2C: 0339CF20 032A0000 + FCF20
0339CE30: FFFFFFFF
0339CE34: 200E2018 1EFD0000 + 1112018
0339CE38: 006CFB54 00400000 + 2CFB54 (vegas80.exe)
0339CE3C: 0339CE78 032A0000 + FCE78
0339CE40: 17D71A88 17D70000 + 1A88
0339CE44: 200E2008 1EFD0000 + 1112008
0339CE48: 2713E4AD
0339CE4C: 07040201 06FD0000 + 70201
0339CE50: 82828280
0339CE54: 80808080
0339CE58: 80808080
0339CE5C: 7F7F7F7F
0339CE60: 060E0203 060D0000 + 10203
> 0339CE80: 010C0501 00400000 + CC0501 (vegas80.exe)
0339CE84: 00000000
0339CE88: 00000000
0339CE8C: 00000000
0339CE90: 89858080
> 0339CEA8: 0103000E 00400000 + C3000E (vegas80.exe)
0339CEAC: 09FEB270 09E10000 + 1DB270
0339CEB0: 0DD2C1D8 0DBC0000 + 16C1D8
0339CEB4: 80818282
0339CEB8: 80808080
Widetrack wrote on 9/26/2008, 8:36 PM
Guess I'm talking to myself here, but with the 2 new GB of RAM, my MP2 render went to about 84% and died right in front of my eyes as I was watching Task Manager showing a nice even 50% - 57% CPU usage and Page file at a flat 1.4 GB.

So I got 0.8 of a render. guess I'll render the rest and see if i can find a way to stitch them together for DVDA.

Maybe Render short segments to AVI, then try to re-render them as MP2 and maybe it won't be too hard on the software to do 34 minutes with no tricky transitions and animations.

****Embarrassing semi-rant removed here*****

Crash dump below.

>>>>>>>>>>>>>>>>>>>>>>

At about 84%

Sony Vegas Pro 8.0
Version 8.0b (Build 217)
Exception 0xC0000005 (access violation) WRITE:0x0 IP:0x1C0D3308
Thread: ProgMan ID=0xB68 Stack=0x339C000-0x33A0000
Registers:
EAX=00000000 CS=001b EIP=1c0d3308 EFLGS=00010246
EBX=ffffffff SS=0023 ESP=0339ce3c EBP=0339d410
ECX=009e0158 DS=0023 ESI=0339cf20 FS=003b
EDX=006295b0 ES=0023 EDI=10bb9ae0 GS=0000
Bytes at CS:EIP:
1C0D3308: 00 00 00 00 00 00 00 00 ........
1C0D3310: 00 00 00 00 00 00 00 00 ........
Stack Dump:
0339CE3C: 0339CE78 032A0000 + FCE78
0339CE40: 18DCC878 187A0000 + 62C878
0339CE44: 1C0D32F8 187A0000 + 39332F8
0339CE48: 50A4D033
0339CE4C: 0B080D0A 0AF40000 + 140D0A
0339CE50: 87878787
0339CE54: 82828484
0339CE58: 7C7C7A7A
0339CE5C: 7D7D7D7D
0339CE60: 09090709 08FD0000 + C0709
0339CE64: 03040606 02FF0000 + 50606 (vfx1.dll)
0339CE68: 12080902 100B0000 + 1FD0902
0339CE6C: 08114151 06FD0000 + 1144151
0339CE70: 80808181
0339CE74: 86868181
0339CE78: 10BB9AE0 100B0000 + B09AE0
> 0339CEA8: 030A0806 02FF0000 + B0806 (vfx1.dll)
0339CEAC: 0FBBA610 0FAC0000 + FA610
0339CEB0: 0FB9D7C0 0FAC0000 + DD7C0
0339CEB4: 81808080
0339CEB8: 80818080
> 0339CEF8: 364D9365 36340000 + 199365 (sfmarket2.dll)
> 0339CF2C: 01030209 00400000 + C30209 (vegas80.exe)
0339CF30: 80808080
0339CF34: 81818180
0339CF38: 80808080
0339CF3C: 80808080
> 0339CF40: 03020000 02FF0000 + 30000 (vfx1.dll)
> 0339CF44: 01010602 00400000 + C10602 (vegas80.exe)
0339CF48: 00020506 00020000 + 506
0339CF4C: 02030302 01FB0000 + 80302
0339CF50: 81818180
0339CF54: 81818181
> 0339CFE0: 7D228E22 7D1E0000 + 48E22 (msi.dll)
> 0339CFFC: 7E298B22 7E290000 + 8B22 (shdocvw.dll)
> 0339D000: 7E478B36 7E410000 + 68B36 (USER32.dll)
> 0339D018: 7C91925D 7C900000 + 1925D (ntdll.dll)
> 0339D01C: 7C9192EF 7C900000 + 192EF (ntdll.dll)
> 0339D03C: 7E418D41 7E410000 + 8D41 (USER32.dll)
> 0339D178: 7C936EB3 7C900000 + 36EB3 (ntdll.dll)
> 0339D184: 7C936EB3 7C900000 + 36EB3 (ntdll.dll)
> 0339D188: 7C936F08 7C900000 + 36F08 (ntdll.dll)
> 0339D19C: 00AD0001 00400000 + 6D0001 (vegas80.exe)
- - -
0339FFF0: 00000000
0339FFF4: 005258F0 00400000 + 1258F0 (vegas80.exe)
0339FFF8: 00ADA678 00400000 + 6DA678 (vegas80.exe)
0339FFFC: 00000000

blink3times wrote on 9/27/2008, 4:17 AM
Most of these crashes appear to be "Access violations" (as per your crash dump statements) which is usually all about writing to a section of memory that's already being used by something else.

I would disconnect EVERYTHING from your machine that is not essential (including your sound card). Go to msconfig and turn off EVERYTHING that is no t absolutely needed to run the machine. I would also goto SERVICES and do the same.... disable EVERYTHING that is not necessary.

I'm not sure if your video card has an option to use system ram (over and above its on-board ram) but if it does then turn it off. Also, unplug any and all usb cables that you may have hooked up.
farss wrote on 9/27/2008, 5:57 AM
Is this an 8 or 32 bit float project?
If 32 bit try switching it to 8 bit.

Bob.
Widetrack wrote on 9/27/2008, 10:09 AM
Blink and Bob:

I think Blink's analysis of the dump and suggestions may be on the money.

After seeing a render die while everything in Task Manager was looking just fine, I re-checked all the other suggestions I'd gotten, and disabled my Fireface 400 (Audio I/O) ASIO drivers and selected instead the Windows classic Wave Driver.

I then looked even closer and found that even though I'd set this machine up as a non-online-stay-home-and-stay-clean-just-say-no cmptr, I hadn't removed one piece of anti-virus software, and it was still in Auto-update mode. Holy operator error, Batman. So I ripped the little beast out by its roots, then turned off windows update, just out of spite.

Bingo. One successful overnight render, just as sweet as you please. And it even took about an hour less than it had before.

Going to render another today, and I am bettin...well, no...hoping it works again.

thank you all for the patient input.

WT

farss wrote on 9/27/2008, 2:39 PM
If that actually fixes the problem then between it and other behavior I've noticed it makes me wonder if something isn't seriously screwed up in Vegas.

Bob.