Crashes in latest VDubMod, DiVX 5.1, AVISynth 2.5.1...

[delusion_]

I'm using the latest "stable" VirtualDubMod (1.5.4.1) and
encountering a problem when encoding AVS to DiVX5.1
using the job control dialog. The encodes are simple; the
audio is left the same (copied over), and I'm using "Fast
Recompress" mode. The DiVX5.1 settings I'm using
are "Standard" speed, 2150kbps bitrate, and setting up
2-pass encodes (add the first pass to the job queue,
then change to nth-pass in DiVX and save as a second
job for the queue.) The first pass will usually get 100%
done, and VirtualDubMod will then crash with this error:

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation)
occurred in module 'ntdll'.

LoadPlugin("C:\AVISynthFilters\2.5\Mpeg2Dec3
\mpeg2dec3.dll")
LoadPlugin("C:\AVISynthFilters\2.5
\Decomb\Decomb500.dll")
mpeg2source("inputmovie.d2v")
FieldDeinterlace()
Crop(10, 6, -10, -6)

I'm using the latest Decomb/MPEG2DEC3 versions (5.00
and 1.10 respectively.)

Any ideas you guys have on this would be appreciated :)
Thanks.


Update -- I've found out that this problem is occuring when VirtualDubMod attempts to CLOSE the AVS file (at the end of the first pass) -- Manually running two passes works, but isn't a viable solution here (I need job control/queues.) It doesn't matter what compressor I use; it's the actual "closing" of the video file that's triggering the error. It's also interesting to note that VirtualDub has the same problem/bug. If anyone needs to see my crash log, let me know and I'll attach it. I'll try to come up with an easier way to reproduce the error. I'm totally stuck here.

[len0x]

I think faced that problem once as well...
But not wishing to test it further rolled back to 1.5.1.1a.

[unmei]

ouch the AVS close error.
I've had this in quite all VDM versions i can think of, but the interesting thing is, i have two boxes both XP with nearly the same video software installed. On the AMD (thunderbird) one the crash always occurs, but on the Intel (P3) the crash does not occur in every version, the build 2107 i now use does not produce it for instance.

Since this behavious is so old and even present in plain VD i guess its quite buried inside the code and probaly had to find (else i cant understand why noone ever cared to solve it...or has it never happened to any of the programmers (?))

If someone had an idea what could cause it...

wrong version DLL, wrong install path of VDM or AviSynth are the ones jumping to my mind,

but i would hate to place the stuff inside "program files" ..but still its quite annoying, so if i knew this would fix it, i'd of course change it :)