i have the same issue ... in the end i gave up and never used multiavcd again ...
+ Reply to Thread
Results 31 to 40 of 40
Some notes about this Win10 install, which actually applies to ALL of my Win10 (and Win7) installs:
(1) I run Win10 Pro. Are you running Win10 Enterprise?
(2) I run with desktop properties at 125%, not 100%. I have high-resolution monitors and at 100% the text rendering is too small. I prefer th clear "dark ink" look to characters rendered at 125%.
Consequently, I also change many of my everyday programs (3rd-party programs) to run in "compatibility mode", pushing the Properties "change high DPI settings" button and then checking "high scaling DPI override setting it to "application". Again, this shouldn't be relevant but it does cause the creation of a Registry key: HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers.
And this is relevant because when I compared my newly created log (on this T495 machine) to your latest log, there was that difference. On my T495 there was an occasional "side trip" looking through that \AppCompatFlags\Layers key specifically looking for an entry for c:\multiAVCHD\tools\MX264.EXE which is NOT present. On your system since there was no \AppCompatFlags\Layers key your trace did not reflect any side-trips.
(3) MX264.EXE is a very critical internal component of multiAVCHD. In fact AVISynth.dll is loaded by MX264.EXE (according to the trace, visible if you also show MX264.EXE entries). For that reason I expanded my ProcMon trace to include its process name as well as multiAVCHD.EXE. I think the trace output from both programs is very important to see, because looking at your trace there seems to be some problem involving MX264.EXE. Since your trace doesn't have its output I can't yet compare those one-level-down entries for significant differences. But I'm suspicious of something related to MX264.EXE.
Can you please re-run your test again, but this time with a second PROCESS NAME filter (include) of MX264.EXE. I'm posting my own trace output here, already including MX264.EXE as well as multiAVCHD.EXE.
However I still think the fundamental problem is revealed much earlier in the trace. As you can see from the following comparison, even though your mysterious QueryEAFile for multiAVCHD.DAT has disappeared, there now is one of them for MX264.EXE. I'm not a programmer at this level, but I'm guessing this is referring to a "program information file" for MX264.EXE, and if not found it gets created. Or something. But whatever is going on, your trace and my trace is different. Perhaps since I've run multiAVCHD multiple times that program information file for MX264.EXE is already created on subsequent requests. For you, the very first time you run your test after installing Win10 there isn't yet an entry for it. Perhaps that's the difference here.
So I think the best thing is for you to run at least two (or even three?0 tests, before capturing the ProcMon output, just to be sure we're not distracted by first-time-only anomalies. We really should be looking at "steady state" symptoms from the 2nd or 3rd test, since you say you can reproduce the failure 100% every time you try it.
Notice the difference in our trace output right at line 28 in file. For my situation MX264's "program information file" seems to have been properly populated with information, probably thus making MX264.EXE "usable". And it's the entryway to AVISYNTH.DLL. In contrast, your trace shows a QueryEAFile entry, perhaps because this is your first time running multiAVCHD. So I'm willing to give it the benefit of the doubt.
But the real problem is then visible a bit further down, at your line 42, which is right at the QuerySecurityFile entry, followed by a QueryNameInformationFile entry. This is really where our two trace outputs diverge. And this pertains to MX264.EXE. So if the access to MX264.EXE is somehow hindered by what's happening here, perhaps that explains why the interface to AVISynth is defective, eventually resulting in the error messages you see.
I don't know what this QuerySecurityFile is all about, but it seems relevant.
[Attachment 56482 - Click to enlarge]
I running Win10Pro as well. Here are the specifications:
Edition Windows 10 Pro
Installed on 12/26/2020
OS build 19042.685
Experience Windows Feature Experience Pack 120.2212.551.0
I launched multiAVCHD and tried to enable menus several times before generating the ProcMon log. Our log files still diverge at about the same point but it's all foreign to me.
I've attached the log as before.
I'm going to try something different later today. Your Win10 environment is "brand new", literally fresh out of the box, when you try to install multiAVCHD and push "create top menu" to get your failure. In contrast, all of my own Win7/Win10 systems where I've had no problem doing the same thing and having it work perfectly are "mature" and fully built-out. That means they have lots of assorted other multi-media software products of all kind also installed, when multiAVCHD is then installed. Shouldn't have anything to do with it but maybe it does.
In other words, perhaps I too should try a brand new 20H2 Win10 install, and do essentially nothing else before immediately seeing if I can install multiAVCHD and then reproduce your same failure. Maybe a "virgin system" will demonstrate the failure which is actually being prevented by the presence of some other 3rd-party software or customization of my actual "production" systems.
I'll have to carve out some time later today to try this. It probably won't be until later tonight or tomorrow before I can report back my results, whatever they turn out to be. I will do as close to absolutely nothing after Win10 comes up for the first time as I can, resisting the urge to do nay customization or other 3rd-party product install.
We shall see what happens.
Anyway, it's not that we don't know the simple installation recipe steps, precisely as Dean shows or slightly different (for AVISynth and FFDSHOW) as ADUB shows. Unimportant. It's something else at work here, because when I follow the "recipe" it works perfectly on now four different machines of mine (both Win7 and Win10), whereas it doesn't for you and some others.
There's more to the story than the installation "recipe". And when we find out what that is it will all now become clear what was behind the fact that some users were having problems in the Win10 environment. Remember, this product has been orphaned for about 10 years.
In a related and probably similar story, I've installed Adobe Photoshop 6 on a number of older Win7 systems for friends and family. This is a very old version brought out in the 90's, so it's probably 25 years old now. Well it can't actually be installed in Win10 any longer because the installer for the product is a 16-bit installer (even though the program itself is a 32-bit program) and support for 16-bit is no longer available with Win10. However Win7 machines that were "upgraded" late last year to Win10 (using MS-provided free upgrade-in-place technique to get everybody off of Win7 and onto Win10) continued to see their already installed Photoshop 6 still run perfectly. As long as you didn't need to reinstall, you could continue to use your already installed version on Win10 which had come through that Win7->Win10 upgrade.
Well, just recently, perhaps with Win10 2004 but for sure now with Win10 20H2, the Photoshop 6 program itself NO LONGER WORKS! Something about the internal changes made by MS sometime this year (or at least in 20H2) now produce an actual incompatibiilty with 25-year old Photoshop 6 32-bit code so that it now launches with a "hardware error" message which is of course meaningless and incorrect, but which cannot be overcome. Permanent hard failure-to-launch now.
The only solution is to uninstall this antique Photoshop 6 and instead install a newer modern version like CS3 or newer. And since Photoshop 6 is abandoned and unsupported, there simply is no way its new problem will ever be "fixed".
My guess is that there's something similar going on with multiAVCHD, and SOME Win10 systems but not other Win10 systems. Perhaps it can operate problem-free on "lesser machines" but encounters some issues unique to "bigger machines". I know that sounds silly to say, but there must be some true underlying explanation why this 10-year old software is now encountering problems operating properly in the new Win10/20H2 world for which it was never designed and originally tested.
For example, my own "successful" machines have 32GB of memory or less. One 32GB, several 16GB. And originally it was 8GB. All successful originally with Win7 and now also all with Win10. Maybe machines with 64GB of memory have some inherent incompatibility with mulriAVCHD.
Anyway, I'm about to start my "fresh install" experiment. More later.
Last edited by DSperber; 28th Dec 2020 at 19:51.
Nope. No difference from before. Installation of everything went problem-free in this brand new Win10 Pro, and multiTEST ran all tests successfully. I used my Lenovo P70 laptop, installing a 20H2 Win10.
Then multiAVCHD also ran fine, including going to the Author tab and checking "create top menu".
ProcMon output for me looks like it did before, which means out-of-sync with yours. I assume you're running ProcMon64.exe as I am.
I cannot explain it. I really tried to build a new Win10 that had virtually nothing changed from default. I didn't install any software products, or change scaling/compatibility for anything. I did set UAC down to "never notify" (because I hate to keep responding YES for many ordinary system changes), and thought that might have something to do with why MX264.EXE might have gotten installed or used differently than if UAC were left where it is initially.
Anyway, I simply cannot duplicate your failure on any of my systems. Don't know what to say or suggest next.
If you have VM enabled on your Win10, you might try creating a Win7-VM and then try installing multiAVCHD and the prerequisite software products in that Win7-VM. If it works in that environment (and I see no reason why it shouldn't) that would be a workaround to bypass whatever is causing the 'native Win10" failure.
Helps to have java installed.I think,therefore i am a hamster.