Adobe Premiere Elements 7.0 hangs while exporting and during peak file generation.

Question

I have Adobe Premiere Elements 7.0 (PRE7). I have a project which is using a single clip from a Mini-DV that was captured with Nero 8. Nero 8 was used because it was captured prior to installing PRE7. The file is 12GB and is on a USB disk drive because I don't have the space on my main hard drive (I have about 11GB free). My project doesn't do too much that's fancy. It merely uses about 20 minutes of the 60 minute Mini-DV captured AVI, and it uses simple transitions between each scene. I also have very simple titles at start and end. No themes or anything else.
I've seen two problems. 1) While editing the project, seemingly (but I'm not positive it's related) while the peek file was being generated, PRE7 would get into a state of using about 40% to 50% CPU, and it would not let me do anything else. The other problem, 2) While using "Share" to export the video to WMA for playback on PC (about 180MB estimated file size according to Adobe), the file is exported to about the last remaining 5 seconds, but then PRE7 goes into that mode of hanging with 40% to 50% CPU usage.
One time when it had this 50% CPU issue, I let it sit overnight, and the export was finished in the morning. The export that time was to a 90MB FLV for posting to the "web" according to the Share wizard. But when I was doing the above (issue #2), it went into the 50% CPU usage but didn't finish after waiting around 2 hours. Even if I were to let it sit that time, and it were to finish, it seems like something's wrong and that this is unacceptable.
When this happens, and PRE7 goes into 50% CPU utilization, there is no pacifier or percentage bar advancing. It usually happens near 100% finished. Only one time did it complete successfully after leaving it unattended at 90% complete for an extraordinary amount of time.
To recap:
C:\ hard drive ---> PRE7, my project.
E:\ USB drive ---> 12GB source AVI file and destination for export.
I saw elsewhere on this forum that someone imported a mini-dv captured AVI into Window Movie Maker and then exported it to Mini-DV from that app. This solved that person's problem with hanging during peak file creation. I had the 50% hang issue during peak file generation but I'm not sure it was related to peak file generation. A peak file was generated in a project which, when exported with share as mentioned above, still did the hang 50% CPU issue. Regardless, I will try the import/export/movemaker thing and report back but I've been trying enough things that I wanted to take a second to ask for assistance.
Does anyone have this issue, and is there a patch or fix?
I might be able to provide a user mode dump of the 50% CPU adobe process. There is some call stack information and I'm wondering if developers would want this info if they don't already have a solution/fix to this bug.
Thanks for any help.

Answer 1

I have some more info on the hang which I've been experiencing during export/share of a project which uses an AVI as its one main clip. Adobe Premiere Elements 7 (PRE7) appears to be hanging because it's looping endlessly in ImporterAVI.prm. I'm wondering if this info can be passed onto Adobe developers and/or if I can submit this information elsewhere for such processing. I also have a process dump file which might be helpful, not to mention the original project files.
I used Process Monitor to help analyze this situation, and prior to PRE7 getting into the endless loop, it appears to be reading from the AVI file little by little, and WMEncodingHelper.exe is writing out little by little to the destination file, both of which I would expect. When PRE7 gets to the end of the import/export, Process Monitor appears to show all the aforementioned disk activity ceasing. I see neither process reading or writing. This would be normal if the share/export procedure had completed. But PRE7 is not complete. It is hung and is operating at 50% CPU utilization.
Far below in this post are technical details which may be helpful to an Adobe developer determine why the importer could get into this endless loop. In those details, there is a jump instruction, "jb ImporterAVI!xImportEntry+0xf32", which will always jump if a particular compare always turns out a certain way. But in my review of the counters being compared, it never will get to a point of exiting. When I modify a flag (the carry flag) to be 0, the loop exits. When I did this, my export/share of my project completed successfully. So it was done, but for some reason, PRE7 was looping and looping in its AVI importor instead of completing the export (aka "Share").
I cannot say that this certainly indicates a bug with PRE7, but it seems to me that there's enough data for Adobe to be at least investigating this particular issue. I'm not the only person who has seen this as there was at least one other message describing the same problem which the user resolved by effectively re-creating the AVI file via a no-op import/export into and out of MovieMaker. My AVI also goes through MovieMaker, import/export, without a hitch.
In a sense, I view PRE7's "share" as essentially an import, processing of imported information (i.e., effects and transitions), and an export. It's an import of all clips into the project at the right times, a processing of all effects, and finally an export to a destination. I realize this is simplistic, but the point I'm making is I have a simple project with a single AVI, and it appears that the "import" portion of PRE7's Share option is choking on the only clip used by this project. I also don't have much but simple transitions and a beginning/ending title on the project, so I'm not thinking this use of PRE7 is much more than what I'm doing with MovieMaker when importing/exporting this AVI.
I fully agree that optimum hardware can be either required or critical for certain types of video editing, but PRE7 is a consumer program and I'm not using anything extensive about it and the symptoms are that PRE7 is looping on its import of a file other programs don't have a problem with. I already tried purchasing a 1TB external, which I'm glad I did, but I really think Adobe developers should look at this issue. There may be a problem with handling certain AVI clips used in a project when those clips come from certain sources. If there is an issue, perhaps it could warrant a fix that would make PRE7 more compatible with these other clips.
Does Adobe have a procedure for people to upload (or mail) projects and files to it so that they can troubleshoot why the importer gets into this state? I also mentioned earlier that I have a full user-mode dump of the process which may be of value to a dev. Can I submit this information anywhere?
Here are textual technical details:
Plug-in which loops: C:\Program Files\Adobe\Adobe Premiere Elements 7.0\Plug-ins\en_US\ImporterAVI.prm
The following are the instructions at the "bottom" of the loop which never ends. Below, I put "***" at the jump instruction I mentioned earler. If I force the carry flag to be 0 at that point, and the jump is skipped, the export completed successfully. Additionally, notice that [esp-0x1c] is 0x2000, and that both eax and edi are 0. When I see it loop, eax stays at 0 and never reaches 0x2000. I wonder if something about the AVI is causing values used by this importer to be such that it causes this endless loop, and if that's the case, and if such values are valid/good, I'm wondering if the importer can be fixed by being able to detect such values so as to not choke (if in fact it's an importer issue).
1239dda2 50 push eax
1239dda3 ffd1 call ecx
1239dda5 8b442424 mov eax,dword ptr [esp+24h]
1239dda9 015c2428 add dword ptr [esp+28h],ebx
1239ddad 03c7 add eax,edi
1239ddaf 83c410 add esp,10h
1239ddb2 3b44241c cmp eax,dword ptr [esp+1Ch]
1239ddb6 89442414 mov dword ptr [esp+14h],eax
; *** This is where it loops around and around.
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2)
ImporterAVI!xImportEntry+0x1040:
1239ddc0 8b542420 mov edx,dword ptr [esp+20h]
1239ddc4 52 push edx
1239ddc5 e810d40000 call ImporterAVI!xImportEntry+0xe45a (123ab1da)
1239ddca 83c404 add esp,4
ImporterAVI!xImportEntry+0x104d:
1239ddcd 5f pop edi
1239ddce 5e pop esi
1239ddcf 5d pop ebp
1239ddd0 33c0 xor eax,eax
1239ddd2 5b pop ebx
1239ddd3 83c428 add esp,28h
1239ddd6 c3 ret
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
3195d9b8 12387545 10590f9c 27c53e00 06b35ff6 ImporterAVI!xImportEntry+0x103a
3195d9ec 1239ea10 06b35ff6 00000000 27ad8a60 ImporterAVI+0x7545
3195da1c 1238aa31 06b3554b 00000000 7fdf0000 ImporterAVI!xImportEntry+0x1c90
00000000 00000000 00000000 00000000 00000000 ImporterAVI+0xaa31
[esp-1Ch]: 3195d9a0 00002000
eax=00000000 ebx=00000000 ecx=3195dbcc edx=00000000 esi=27ad8a60 edi=00000000
eip=1239ddba esp=3195d984 ebp=3c7ba50b iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000287
ImporterAVI!xImportEntry+0x103a:
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2) [br=1]