Stackdump when encoding, Vista issue, or something else?
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
-
- Posts: 1
- Joined: Tue Mar 20, 2007 12:31 am
Stackdump when encoding, Vista issue, or something else?
sr55:
I don't have a 2000 or XP box with which to test this, so it may very well be a "not ready for Vista" issue.
When clicking on "Encode Video", I get the initialization dialogue for the CLI, click on OK, and then no console window. I then get a stackdump file in the output folder I have chosen.:
Exception: STATUS_ACCESS_VIOLATION at eip=0040E271
eax=00000000 ebx=01783018 ecx=00000000 edx=00000000 esi=01782FC0 edi=1AFFCE64
ebp=1AFFCD48 esp=1AFFCBC0 program=C:\Program Files\Handbrake\hbcli.exe, pid 2720, thread unknown (0xF60)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
1AFFCD48 0040E271 (01782F38, 00000000, 00000000, 01783018)
1AFFCD68 00409FCC (01782F50, FFFFFFFF, 611668E0, 610040DA)
1AFFCDA8 610AFC21 (01782FC0, 1AFFCDE0, 610AFBC0, 1AFFCDE0)
610AFBC0 61004416 (8908758B, 5E8D2434, D82AE858, 7B83FFFF)
60695 [unknown (0xF60)] hbcli 2720 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
61385 [unknown (0xF60)] hbcli 2720 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
I've tried enabling compatibility modes (XP:SP2 & 2000) as well as flagging both the GUI and the CLI to run as Administrator. It doesn't change the problem.
Is this addressable? Failing that, given that you've stated that you don't have access to a Vista box, is there any testing that I could be doing to provide you with more data?
I don't have a 2000 or XP box with which to test this, so it may very well be a "not ready for Vista" issue.
When clicking on "Encode Video", I get the initialization dialogue for the CLI, click on OK, and then no console window. I then get a stackdump file in the output folder I have chosen.:
Exception: STATUS_ACCESS_VIOLATION at eip=0040E271
eax=00000000 ebx=01783018 ecx=00000000 edx=00000000 esi=01782FC0 edi=1AFFCE64
ebp=1AFFCD48 esp=1AFFCBC0 program=C:\Program Files\Handbrake\hbcli.exe, pid 2720, thread unknown (0xF60)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
1AFFCD48 0040E271 (01782F38, 00000000, 00000000, 01783018)
1AFFCD68 00409FCC (01782F50, FFFFFFFF, 611668E0, 610040DA)
1AFFCDA8 610AFC21 (01782FC0, 1AFFCDE0, 610AFBC0, 1AFFCDE0)
610AFBC0 61004416 (8908758B, 5E8D2434, D82AE858, 7B83FFFF)
60695 [unknown (0xF60)] hbcli 2720 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
61385 [unknown (0xF60)] hbcli 2720 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
I've tried enabling compatibility modes (XP:SP2 & 2000) as well as flagging both the GUI and the CLI to run as Administrator. It doesn't change the problem.
Is this addressable? Failing that, given that you've stated that you don't have access to a Vista box, is there any testing that I could be doing to provide you with more data?
What program are you using to decrypt the DVD's?
AnyDVD is really good. http://www.slysoft.com/en/download.html for a 21day trial.
Also have you tried other DVD's?
AnyDVD is really good. http://www.slysoft.com/en/download.html for a 21day trial.
Also have you tried other DVD's?
sr55,
I have the same problem, But I found a way around, when I try to encode the comand prompt window shows minimized and then closes and leaves stack dump file (something like that), I found that if you browse destination and select output file format to mp4 (from the drop down window) if you do this twice it works.
I Hope that helped, and made sense
crown
I have the same problem, But I found a way around, when I try to encode the comand prompt window shows minimized and then closes and leaves stack dump file (something like that), I found that if you browse destination and select output file format to mp4 (from the drop down window) if you do this twice it works.
I Hope that helped, and made sense
crown
Might this be a DVD-dependent issue? I am running XP (Media Center Edition) and decrypting with DVD43. I have successfully encoded 2 movies, but when I try to encode Indepence Day, it starts fine and actually runs along for almost 90% of the way, then stackdumps. I have tried it several times with the same result.
I too get stack dumps on XP SP2
My most recent:
Exception: STATUS_ACCESS_VIOLATION at eip=610B5102
eax=9952444A ebx=00FCA268 ecx=61147E34 edx=9952444A esi=61147E34 edi=00FCA268
ebp=0022AC28 esp=0022AC10 program=C:\Program Files\Handbrake\hbcli.exe, pid 3672, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022AC28 610B5102 (00FCA268, 00D50008, 0022AC48, 610AD46C)
0022AC48 610ACBF8 (00FCA268, 00D50008, 0022AD28, 0022AC30)
0022AD48 610ACD5C (0022B2D4, 0022B270, 00955308, 0022C9C8)
0022C968 610E10FE (0022D008, 61101150, 00955308, 0022C9B8)
0022C988 610E46E8 (61101150, 00955308, 0022C9B8, 6108BE93)
0022C9A8 610E470F (61101150, 00955308, 00000001, 00000002)
0022CA68 61092B48 (00D51120, 0022CBF8, 0022C9B0, 0022C990)
0022CC18 004014D4 (00000017, 00D51048, 00D50090, 61011C0E)
0022CD98 61006148 (00000000, 0022CDD0, 610054C0, 0022CDD0)
610054C0 61004416 (0000009C, A02404C7, E8611001, FFFFFF48)
308653 [main] hbtest 3672 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
328273 [main] hbtest 3672 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
My most recent:
Exception: STATUS_ACCESS_VIOLATION at eip=610B5102
eax=9952444A ebx=00FCA268 ecx=61147E34 edx=9952444A esi=61147E34 edi=00FCA268
ebp=0022AC28 esp=0022AC10 program=C:\Program Files\Handbrake\hbcli.exe, pid 3672, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022AC28 610B5102 (00FCA268, 00D50008, 0022AC48, 610AD46C)
0022AC48 610ACBF8 (00FCA268, 00D50008, 0022AD28, 0022AC30)
0022AD48 610ACD5C (0022B2D4, 0022B270, 00955308, 0022C9C8)
0022C968 610E10FE (0022D008, 61101150, 00955308, 0022C9B8)
0022C988 610E46E8 (61101150, 00955308, 0022C9B8, 6108BE93)
0022C9A8 610E470F (61101150, 00955308, 00000001, 00000002)
0022CA68 61092B48 (00D51120, 0022CBF8, 0022C9B0, 0022C990)
0022CC18 004014D4 (00000017, 00D51048, 00D50090, 61011C0E)
0022CD98 61006148 (00000000, 0022CDD0, 610054C0, 0022CDD0)
610054C0 61004416 (0000009C, A02404C7, E8611001, FFFFFF48)
308653 [main] hbtest 3672 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
328273 [main] hbtest 3672 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
Noone really understands why this happens.
I suspect its down to something going from with the CYGWIN enviroment. The application is not native on windows and instead has the cygwin1.dll looking after it. I suspect that something in handbrake is alittle dodgy and is enough to cause problems with CGYWIN. Its hard to say.
I suspect its down to something going from with the CYGWIN enviroment. The application is not native on windows and instead has the cygwin1.dll looking after it. I suspect that something in handbrake is alittle dodgy and is enough to cause problems with CGYWIN. Its hard to say.
I continue to find that encoding small files, say one or two chapters, works fine and produces excellent results. However, if I try to encode a full movie, HB proceeds all the way to the end producing a large, but unreadable file as well as a stackdump.
Is this new behavior? Did HB once work on XP SP2? Scott, does this ever happen to you? Or, is this something with my system in particular?
Is this new behavior? Did HB once work on XP SP2? Scott, does this ever happen to you? Or, is this something with my system in particular?
I've seen a stackdump but it seems a rarity for me.
As i said, I believe its down to the CYGWIN enciroment its compiled under.
in plain english or as near as i can:
CYGWIN handles all the requests handbrake makes to the Operating System.
The reason this is needed is because handbrake is not native under windows. You cannot compile handbrake natively using any of the compilers available for windows.
To get around this what we are doing is compileing it under an emulated Linux enviroment, cygwin. What this is doing is, when Handbrake makes a call to the operating system, the CYGWIN dll is emulating a linux responce and controling Windows accordingly.
The problem the CYGWIN is its far from perfect. The way the libaries and handbrake are compiled is not perfect and issues with the code that would not normally cause a problem under Linux or OSX will cause an issue under CYGWIN. The reason will be down to cygwin not being able to handle all possible requests on the operating system that handbake may make. IF something funny happens, CYGWIN probably won't know how to handle it and therefore die.
This is what i believe is happening.
Now, my own experience is this: Its only a few select DVD's that i've seen this happen with. Sometimes ripping to HD then re-ripping with handbrake has got around it. Its not something i see very often.
I have a few suspicions as to what may cause it to happen more often:
1. The amount of free ram
2. Other applications open (that may or may not be accessing the DVD) e.g opening my computer may cause Windows to read the DVD for titlename.
3. Stalls whilst reading the DVD, DVD decryption software stalling or passing a malformed packet of data.
I'm using AnyDVD, the latest version for all encodes and so far so good. Very few issues.
DVD43 however gave me a few problems. It also does not support as many copy protection schemes are AnyDVD
As i said, I believe its down to the CYGWIN enciroment its compiled under.
in plain english or as near as i can:
CYGWIN handles all the requests handbrake makes to the Operating System.
The reason this is needed is because handbrake is not native under windows. You cannot compile handbrake natively using any of the compilers available for windows.
To get around this what we are doing is compileing it under an emulated Linux enviroment, cygwin. What this is doing is, when Handbrake makes a call to the operating system, the CYGWIN dll is emulating a linux responce and controling Windows accordingly.
The problem the CYGWIN is its far from perfect. The way the libaries and handbrake are compiled is not perfect and issues with the code that would not normally cause a problem under Linux or OSX will cause an issue under CYGWIN. The reason will be down to cygwin not being able to handle all possible requests on the operating system that handbake may make. IF something funny happens, CYGWIN probably won't know how to handle it and therefore die.
This is what i believe is happening.
Now, my own experience is this: Its only a few select DVD's that i've seen this happen with. Sometimes ripping to HD then re-ripping with handbrake has got around it. Its not something i see very often.
I have a few suspicions as to what may cause it to happen more often:
1. The amount of free ram
2. Other applications open (that may or may not be accessing the DVD) e.g opening my computer may cause Windows to read the DVD for titlename.
3. Stalls whilst reading the DVD, DVD decryption software stalling or passing a malformed packet of data.
I'm using AnyDVD, the latest version for all encodes and so far so good. Very few issues.
DVD43 however gave me a few problems. It also does not support as many copy protection schemes are AnyDVD
Well i upgrade cygwin a few days ago so that would be both.
I will of course be bundling the newer verion with the new gui when thats out within the next week or 2 pending no major problems.
I've actually got a DVD here, Open Season. This one cause a stack dump every time however the encode process keeps running to 99.8% where the audio gets droped, finishes to 100% then stalls.
First Dvd i've found to consistantly cause issues so i'm going to play around a bit see what works, what doesn't.
I also thought i'd try updating GCC under cygwin to the latest version if possible. They use 3.4.4 atm and 4.1.2 is the latest. I figured i'd give that a go see what happens. I was hoping it might fix a stack allighment issue in mpeg4.
I will of course be bundling the newer verion with the new gui when thats out within the next week or 2 pending no major problems.
I've actually got a DVD here, Open Season. This one cause a stack dump every time however the encode process keeps running to 99.8% where the audio gets droped, finishes to 100% then stalls.
First Dvd i've found to consistantly cause issues so i'm going to play around a bit see what works, what doesn't.
I also thought i'd try updating GCC under cygwin to the latest version if possible. They use 3.4.4 atm and 4.1.2 is the latest. I figured i'd give that a go see what happens. I was hoping it might fix a stack allighment issue in mpeg4.
I am very new to this and am attempting to use Handbrake to rip my dvds for viewing on an apple tv.
i'm running windows vista and was only able to get handbrake to begin the encoding process after using AnyDVD (v 6.1.3.3) then using DVDshrink (v 3.2) to copy to the hard drive first. Handbrake goes through the entire encoding process to 100% then gives me the stackdump. I've tried this with 4 dvds so far and am getting the same thing over and over.
also, if i try to start the encoding task again, it immediately gives me the stackdump file after flashing the command prompt for a moment.
is there anything else i could try?
Thanks for all your help!
Exception: STATUS_ACCESS_VIOLATION at eip=0040E271
eax=00000000 ebx=01DF2730 ecx=00000000 edx=00000000 esi=01DF26D8 edi=1A1DCE64
ebp=1A1DCD48 esp=1A1DCBC0 program=C:\Program Files\Handbrake\hbcli.exe, pid 3832, thread unknown (0xB90)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
1A1DCD48 0040E271 (01DF2600, 00000000, 00000000, 01DF2730)
1A1DCD68 00409FCC (01DF2618, FFFFFFFF, 611668E0, 610040DA)
1A1DCDA8 610AFC21 (01DF26D8, 1A1DCDE0, 610AFBC0, 1A1DCDE0)
610AFBC0 61004416 (8908758B, 5E8D2434, D82AE858, 7B83FFFF)
398995 [unknown (0xB90)] hbcli 3832 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
471504 [unknown (0xB90)] hbcli 3832 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
i'm running windows vista and was only able to get handbrake to begin the encoding process after using AnyDVD (v 6.1.3.3) then using DVDshrink (v 3.2) to copy to the hard drive first. Handbrake goes through the entire encoding process to 100% then gives me the stackdump. I've tried this with 4 dvds so far and am getting the same thing over and over.
also, if i try to start the encoding task again, it immediately gives me the stackdump file after flashing the command prompt for a moment.
is there anything else i could try?
Thanks for all your help!
Exception: STATUS_ACCESS_VIOLATION at eip=0040E271
eax=00000000 ebx=01DF2730 ecx=00000000 edx=00000000 esi=01DF26D8 edi=1A1DCE64
ebp=1A1DCD48 esp=1A1DCBC0 program=C:\Program Files\Handbrake\hbcli.exe, pid 3832, thread unknown (0xB90)
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
1A1DCD48 0040E271 (01DF2600, 00000000, 00000000, 01DF2730)
1A1DCD68 00409FCC (01DF2618, FFFFFFFF, 611668E0, 610040DA)
1A1DCDA8 610AFC21 (01DF26D8, 1A1DCDE0, 610AFBC0, 1A1DCDE0)
610AFBC0 61004416 (8908758B, 5E8D2434, D82AE858, 7B83FFFF)
398995 [unknown (0xB90)] hbcli 3832 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
471504 [unknown (0xB90)] hbcli 3832 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
I had first tried to encode straight from the dvd but i couldn't get it to find any titles when reading the dvd. not sure if it has anything to do with it yet but i was able to eventually do that after i turned off user account control (UAC) in vista. however i still got the same stackdump once i was able to encode straight from the dvd.
i'm trying it on an xp machine right now and will let you know if i get the same results.
i'm trying to encode a dvd of the incredibles and it should be region 1.
i'm trying it on an xp machine right now and will let you know if i get the same results.
i'm trying to encode a dvd of the incredibles and it should be region 1.
alright, seemed to work okay with xp. finished the encoding and got a nice big .avi file at the end of it all. when i try to play it, i only have audio and no video though (windows media player), in quicktime it only plays for 1 second with no audio or video and it wont let me add it to my itunes library...was that probably caused by something in my settings?
i used h.264 with aac and the video is 285kbps
i used h.264 with aac and the video is 285kbps
IMPORTANT NEWS
I've recompiled Everything apart from libdvdread under GCC4.1.1 instead of GCC 4.3.4.
The stack allignment warning for libavcodec is now resolved.
I believe this may reduce stack dumps that have been happening.
Heres a link
http://download.m0k.org/handbrake/hbcli.exe
Please note that this is the latest code out the SVN so there may be other bugs that have appeared and incomplete features if you use the CLI. Hopefully for most there will be no issue here.
I've recompiled Everything apart from libdvdread under GCC4.1.1 instead of GCC 4.3.4.
The stack allignment warning for libavcodec is now resolved.
I believe this may reduce stack dumps that have been happening.
Heres a link
http://download.m0k.org/handbrake/hbcli.exe
Please provide feedback if this release is any more stable.Place the file in, C:\program files\handbrake or wherever you installed it.
Please note that this is the latest code out the SVN so there may be other bugs that have appeared and incomplete features if you use the CLI. Hopefully for most there will be no issue here.
I didn't say it would fix it completely. Its appears to have stoped it from occuring sometimes.
Open_season before, 7/10 times would cause a stackdumo if you did a ctrl-c during the encode. Now its around 1/10times so i assume the stack misalignment with libavcodec was casuing that one.
However the problem is other libaries may well be causing your particular stackdump.
Theres not really anything more that can be done, to my knowledge, at the moment.
Open_season before, 7/10 times would cause a stackdumo if you did a ctrl-c during the encode. Now its around 1/10times so i assume the stack misalignment with libavcodec was casuing that one.
However the problem is other libaries may well be causing your particular stackdump.
Theres not really anything more that can be done, to my knowledge, at the moment.