[Bug] MP crashes during recording playback (1 Viewer)

[cfforce]

I've downloaded the new TSreader.ax (25251) from the svn; and crashing on recordings are gone for now; installed it on the pre-rc2 disater123 edition.

 

[tourettes]

I've downloaded the new TSreader.ax (25251) from the svn; and crashing on recordings are gone for now; installed it on the pre-rc2 disater123 edition.

How often it was crashing with the earlier binary? How much have you been testing with the SVN one? I'm asking since I haven't seen the crash anymore with the SVN TsReader (been using it with the RC1 MP for two weeks).

 

[dhasselqvist]

I'm asking since I haven't seen the crash anymore with the SVN TsReader (been using it with the RC1 MP for two weeks).

I don't know if you missed my post from yesterday but I have now got the crash when TsReader was not even in use. So my conclusion is that this has nothing to do with TsReader but with video playback in general in MP.

 

[arion_p]

@tourettes: I've had a similar crash a couple of times. In one occasion I attached VS debugger to see where it crashed and then I saw the real exception which was "buffer overrun".

.NET adds guard cookies on the stack in each call, and if those are corrupt on return it throws the "buffer overrun" exception. However by the time you hit the exception all stack trace is lost and tracking the source of the problem is impossible. Not sure though that this is a TsReader issue.

I wanted to clarify this a bit more. It is (in theory) impossible to get a buffer overrun in C# (at least not one that would throw this exception and generaly cause unrecoverable errors) because all managed memory allocations are from heap memory not the stack. There are only 3 possible causes:

1. bug in .Net Framework (not impossible but unlikely to have not been spotted so far)
2. an "unsafe { }" code block
3. C++ code.

The fact that the exception occurs in mscorwks.dll does not rule out C++ as that is where the managed/unmanaged marshaling takes place, and it is there that the stack is checked on return to make sure it has not been corrupted by the unmanaged C++ code. So I still think the most probable cause is C++ code (not necessarily TsReader).

 

[jameson_uk]

I'm asking since I haven't seen the crash anymore with the SVN TsReader (been using it with the RC1 MP for two weeks).

I don't know if you missed my post from yesterday but I have now got the crash when TsReader was not even in use. So my conclusion is that this has nothing to do with TsReader but with video playback in general in MP.

me too MP just died on me when playing back an MKV file (after watching TV).

The TV has actually lost connection over HDMI and thinks it is not getting a signal now. If I VNC in I get the mediaportal.exe has crashed screen and a massive error report seems to be being sent to MS.

I am assuming the MP team do not have an account to see the crashes as a result of mediaportal.exe (http://www.microsoft.com/whdc/winlogo/maintain/StartWER.mspx) as I would have thought a Verisign ID would be too costly?

Would the hdmp and mdmp files from the crash(es) be of any use??

 

[cfforce]

On recording it was crashing after 2 mins, completly reproducable; now after watching 3 hours of recorded tv (SD/HD) no windows messages "Mediaportal doesn't respond..."
Installed the SVN (rc1 / pre-rc2) friday on my live system; 3 tuners; 3 clients; no problems so far ;P (watching live TV; recording alot @ night etc.). I've tried the new SVN tsreader.ax yesterday.
I haven't tested MKV containers that much.

 

[tourettes]

@tourettes: I've had a similar crash a couple of times. In one occasion I attached VS debugger to see where it crashed and then I saw the real exception which was "buffer overrun".

.NET adds guard cookies on the stack in each call, and if those are corrupt on return it throws the "buffer overrun" exception. However by the time you hit the exception all stack trace is lost and tracking the source of the problem is impossible. Not sure though that this is a TsReader issue.

I wanted to clarify this a bit more. It is (in theory) impossible to get a buffer overrun in C# (at least not one that would throw this exception and generaly cause unrecoverable errors) because all managed memory allocations are from heap memory not the stack. There are only 3 possible causes:

1. bug in .Net Framework (not impossible but unlikely to have not been spotted so far)
2. an "unsafe { }" code block
3. C++ code.

The fact that the exception occurs in mscorwks.dll does not rule out C++ as that is where the managed/unmanaged marshaling takes place, and it is there that the stack is checked on return to make sure it has not been corrupted by the unmanaged C++ code. So I still think the most probable cause is C++ code (not necessarily TsReader).

If following are taking into consideration:

1) also MKV crash (impossible to be a TsReader bug, unless the tv / recording was on before starting the MKV file)
2) happens on XP & Windows 7 / Vista -> cannot be VMR9 / EVR presenter since they aren't sharing code that is executed on run time

We are getting either multiple different issues, or something really odd is happening... or some of those unsafe{} blocks is leaking badly in some cases.

I still would suspect the TsReader since it deals a lot with data and buffer overflow would be pretty easy to cause in such content... but that one MKV related crash is odd...

 

[jameson_uk]

Is there a chance it could be a third party codec causing the issue or would this get flagged elsewhere??

Just noticed after my crash that there was an FFDShow video icon in the task but video I was playing was H264 but I have actually set the Cyberlink PowerDVD 7 codec to run as my H264 codec for videos. Just built a graph and by default the FFDShow DXVA decoder was chosen but the Cyberlink one fitted in nicely as well with a working graph.

Just seemed odd as there is no reason why there should have been any instance of an FFDShow video decoder running.

Just thought I would flag this incase it made a difference.

edit: thinking about it too, I have three crashes with hdmp/mdmp files now and two of those were cetainly with HD H264 material. Need to leave for work now but when I will get back I will see if MP is building the graph I have asked for in config (ie using the Cyberlink codec) or just using a default graph.

 

[dhasselqvist]

1) also MKV crash (impossible to be a TsReader bug, unless the tv / recording was on before starting the MKV file)

....

I still would suspect the TsReader since it deals a lot with data and buffer overflow would be pretty easy to cause in such content... but that one MKV related crash is odd...

Just to clarify so I don't throw you off; TV was on before I played the MKV file (I always start TV module when MP starts, via script, as it's main purpose is to be a DVB-T "box") but when starting the MKV I always stop TV with stop button before playing the video file. But perhaps the corruption was already inserted and not removed before starting my MKV file?

Since two users now have had a crash also when playing non .ts files its not a one time event any more (but both times TV was on before the MKV was played).

I am using the new TsReader that you posted here in this thread earlier. But I still get the same amount of crashes. So at least here it does not cure the problem. But I'm not sure if I'm doing everything right; is it enough to just overwrite the tsreader.ax in my MP directory with the new file for it to be used or do I need to register it in some other way?

 

[joz]

Just experienced the same crash, I think.
attached my logs.
My roommate experienced the crash, het told me he was not doing anything special. Have checked the logs a bit myself but couldn't find anything special.