.net client 1.3.3 crashes on XPSP3

Asked by John Spackman

Hi

I’m finding that the Xibo .NET Client 1.3.3 reproducably crashes on XPSP3; it seems to always make at least one run through all of the videos in the layout (this layout has two videos), but then silently disappears. Sometimes it dies after a few minutes, and the longest it's lasted is around 10 minutes.

I’ve added the tracing options and couldn’t see much so I built my own from the current Bazar source and the problem still occurs. By remote debugging I can see that an AccessViolation is raised in Program.cs in the call to Application.Run(formMain). Here’s the stack trace:

[Managed to Native Transition]
 System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason, int pvLoopData) + 0x24e bytes
 System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context) + 0x177 bytes
 System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x61 bytes
 System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x31 bytes

XiboClient.exe!XiboClient.Program.Main(string[] arg) Line 68 + 0x8 bytes C#

My XPSP3 install is a fresh install on a virtual machine with .NET3.5 SP1 and all Windows Updates applied, I’ve tried creating new layouts and installing a whole new XPSP3 virtual machine and can reproduce the problem each time.

This does not occur on my Windows 7 development machine or on my physical Windows 7 Home Premium display unit. I have not been able to test this on a physical XPSP3 display unit.

Any ideas what else I can try?

Thanks
John

Question information

Language:
English Edit question
Status:
Solved
For:
Xibo Edit question
Assignee:
No assignee Edit question
Solved by:
Dan Garner
Solved:
Last query:
Last reply:
Revision history for this message
Best Dan Garner (dangarner) said :
#1

Linked existing bug, there were lots of changes trying to fix this (was a right pain).

Turns out its the event raised in VideoPlayer.cs, which raises an event to Video.cs, which then signals that it is expired... so region destroys it and loads the next content... however once we are back in the Message Loop we go back out the call stack until we get back to....... VideoPlayer.cs, which doesnt exist anymore.

We don't have control over what the WMP control will do after that event is raised... and clearly it does bad things.

To solve for you - take the entire Video.cs file, and copy into yours.

Revision history for this message
John Spackman (john-spackman) said :
#2

Hi Dan

Brilliant - thanks very much, that's fixed it!

John

Revision history for this message
John Spackman (john-spackman) said :
#3

Thanks Dan Garner, that solved my question.

Revision history for this message
Dan Garner (dangarner) said :
#4

Thanks for posting back - good to know when these fixes actual work for others too!