LORMonitor has stopped working

[Kyle Whitaker]

Help!  I need to figure out if I can get this resolved or if I need to go out and buy a new computer before the season starts.

 

Running LOR 4.3.24 on Windows 10.

This was happening sometimes last year during the show and I could never figure out when and why.

I hooked up the laptop and decided to run it for a while to make sure everything was running before the season starts.  It ran for about 1 hour and 50 minutes and then stopped running.

 

On screen was a window that says: 

LORMonitor has stopped working

A problem caused the program to stop working correctly.  Windows will close the program and notify you if a solution is available.

I click close program and it closes.

I looked at the LORCommListener.exe (dos looking window that always runs) and it shows an error when it "died"

2017-10-30 16:20:46 2:Listener [ERROR] Socket 127.0.0.1:18882 (Show Player), error 10054 on recv

2017-10-30 16:20:46 25:Listener [INFO] Socket 127.0.0.1:18882 (Show Player), existing

[Kyle Whitaker]

I also found this in the Windows Event Viewer.

 

Faulting application name: LORMonitor.exe, version: 4.3.0.18, time stamp: 0x5840d286
Faulting module name: atiumdag.dll, version: 9.14.10.1128, time stamp: 0x55c40703
Exception code: 0xc0000005
Fault offset: 0x0006b627
Faulting process id: 0x1e30
Faulting application start time: 0x01d351ad23b02d3f
Faulting application path: C:\Program Files (x86)\Light-O-Rama\LORMonitor.exe
Faulting module path: C:\WINDOWS\SYSTEM32\atiumdag.dll
Report Id: 56141d5c-2a7c-4784-ac97-27d01b8dc8a8
Faulting package full name:
Faulting package-relative application ID:

[PhilMassey]

Atiumdiag is a dll associated with ATI graphics cards or chips.

The first thing I would do is see if there is an update for the laptops video drivers.

You might also Google atiumdiag.dll for further information

Before buying a new laptop, I would try a clean reinstall of Windows.

[dougd]

Do a search on the forums for LORmonitor.

I thought they were pre-patching the file but you might need to patch it yourself.

[dibblejr]

Join the 4.3.24 issue club. I rolled back. That was just one of the many errors that started popping up on my screen. LOR system tray was the straw that broke the camels back, shut down my show after 2 sequences each time it started.

JR

[Kyle Whitaker]

JR,

 

This happened to me last year on  4.3.16.  Dev said something about a fix in 4.3.18 for video issues (I run video and not just audio files).  I upgraded to 4.3.18 and it worked for about a week before dying again.  What version did you roll back to?

[dibblejr]

7 minutes ago, PhilMassey said:

Atiumdiag is a dll associated with ATI graphics cards or chips.

The first thing I would do is see if there is an update for the laptops video drivers.

You might also Google atiumdiag.dll for further information

Before buying a new laptop, I would try a clean reinstall of Windows.

None of the above worked for me. I use my laptop for sequencing. However during testing I used it to test and eventually upgraded to 2.4.24. About a week into it while sequencing started having issues but we get used to the small stuff. Set up my Halloween and tested everything with laptop, no problems. Then I exported a Thriller matrix sequence from SS to SE and there are to many problems to list.

After a couple days of troubleshooting submitted a HD ticket. Brian discovered a pre ramp prior to the music starting that SE did not catch. I could not copy paste the first 2 rows of a sequence. I kept thinking "the sequence looked strange" before discovering that. Even copy paste channels 1 &2 separately SE would not paste them.

After Brian fixed the sequence all ran good for 1 day until the problems got worse. Under the advisement of the HD I rolled back to 4.3.18. I also tried 2 of my desktops one of which is twice as fast as my laptop with a gaming graphic car and ssd drive. Both with 4.3.24 and wer virgins to LOR software. Started having problems with both so now everything is rolled back to .18 and having problems. ASUS checked out the desktop and found 0 problems. 

Yet neither of the desktops will get past 2 sequences but my slower laptop will play an entire show without fail. All WIN10 home based systems. Desktop 32 gb memory and video card with 8gb memory. Laptop has 2 gb memory video vard and 16 gb ram.

All I need to figure out why LOR sytem tray is shutting down and I can run my show with the desktop. It will allow me to go back to sequencing with my laptop in the evenings.

Still awaiting LOR engineer results.

JR

[dibblejr]

11 minutes ago, Kyle Whitaker said:

JR,

 

This happened to me last year on  4.3.16.  Dev said something about a fix in 4.3.18 for video issues (I run video and not just audio files).  I upgraded to 4.3.18 and it worked for about a week before dying again.  What version did you roll back to?

I never had a problem with .14 or .18 until I upgraded to .24. I thought I needed the small improvements in SS. Wished I never installed .24 now. Today I am having more issues. I sequence faces and many times when I try to find my sweet spot in a word I push play and it repeats itself 3 times and then SE freezes. It will not even X out. Have to restart computer

I needed .18 because I added pixie16's.

JR

Edited October 30, 2017 by dibblejr

[Kyle Whitaker]

Well, I'd love to get some insight from a developer or someone from LOR staff but the HelpDesk link doesn't seem to be working?

[dibblejr]

2 minutes ago, Kyle Whitaker said:

Well, I'd love to get some insight from a developer or someone from LOR staff but the HelpDesk link doesn't seem to be working?

As far as I know there is no answer. My tickets been open for 3 weeks or so. Apearently I was the first to experience and report so they were trying to come up with a solution before others start experiencing the same problem. I called in last week and I got a sort of "canned reply". "Computer has a soft spot in HDD" change computer. Well how about the other 2. And The laptop was purchased in April, desktop was almost top of the line about a year ago. Both mfg did tests and no problems exist. All disk sectors are good and no prob with SSD drive 500 go.

Ive got a new laptop Alienware 17 R4 headed my way and it will get nothing more than 4.3.18 and dedicated to show only just as my desktop. 

JR

[Kyle Whitaker]

I updated my video driver (from AMD instead of HP's site).  It ran again for over 12 hours straight this time before crashing again.  Same errors but this time Faulting module path: unknown.

Does LOR support monitor these posts since their help desk is down?

I need to know if I should reload the laptop (serious pain), roll back to an earlier version of LOR, get a new laptop, or try something else.

[DevMike]

I replied to your ticket.  The issue is outside of our software if the faulting module is that ATI dll.  If the faulting module path is 'Unknown' then that is within Windows itself.

As for the comments about .16/etc being more stable, you will want to look outside our software for any changes you may have made to your computer.  There have been no changes that would create any of the issues you are seeing (like the audio file problem or Monitor/Listener/etc crashing).  The only changes between 16 and 24 were in the hardware utility, Superstar and SD card creation.  There was a single bug in the SE that would only come up if you used insert device for a pixie.  You can verify that yourself by looking at the what's new page.

I know many of you won't believe this (as previous history would suggest).  Please remember that a computer (or software) does not run in a neat little box.  Many things are inter-related - even things you THINK are not related can be.  When things stop working that were working, you need to look at what changed.  Since I have access to the code, I can see what changed on our end.   

I checked the last time we made any change to the listener and it was for version 4.3.6.  That was 20 months ago, and it was only for MBCS computers (like Japanese language):

Revision 15703 - Directory Listing 
Modified Tue Mar 8 21:20:05 2016 UTC (19 months, 3 weeks ago) by bob 
Original Path: trunk/LORCommListener
VB interface to the Comm Listener wasn't behaving well under Japanese systems (and assumedly other multibyte systems).

The change before that was more than 2 years ago and only to the icons.

Revision 15124 - (view) (annotate) - [select for diffs] 
Modified Sun Oct 4 21:01:12 2015 UTC (2 years ago) by bob 
Original Path: trunk/LORCommListener/LORCommListener.rc 
New main app icons used by VB6 stuff and the Comm Listener.

The last change to LORMontior (which encompasses LORtray as well as the show player/etc) was a year ago.  That is the one that was correctly identified as fixing an issue with video playback in 4.3.16:

Revision 16106 - (view) (annotate) - [select for diffs] 
Modified Wed Oct 26 18:07:27 2016 UTC (12 months ago) by MattBrown 
File length: 79525 byte(s) 
Fix for video playback in V4 show player.

The totality of that fix was changing 1 line:

If NewState = wmposMediaOpen Then - old        
If NewState = wmppsPlaying Then - new

I looked at that entire module.  Even if that is still not right, it does not lead to any race condition or crash.  The worst that can happen is a video window that pops up when it shouldn't, or a video window doesn't pop up when it should.

Even more important is that all that code has already gone through 1 full season.  If there were issues with it, they would most certainly popped up last year.  We are very good at identifying patterns and we haven't seen any.

The fact that a different computer runs our software fine pretty much tells you were the problem is:  the computer.  Our code would be identical between the 2 machines, so what is different is where the issue is.  And when we say 'There is an issue with the computer', that issue is most likely operating system or software you installed.  RARELY is it hardware related.

What many of you don't understand is that installing ANY piece of software on your computer can modify the way Windows operates.  That is the power of Windows and why we can write neat things like the LOR software.  The problem is that there is a ripple effect - if one of those doesn't quite deal with something in the chain correctly, that can cause problems outside of that code.  More worse:  Sometimes it takes just the right combination of programs to cause a problem.  Worst:  Maybe it's the ORDER they were installed in!

So for example, you use 'Program X' a lot.  So you install 'Program X' on every computer you have.  Program X however has an issue where it may not expect a perfectly legal value for something in Windows.  It throws a fit, and we get something completely out of whack.  We use that for another operation and whammo.  Things die.  Every computer you own breaks our software.  For you the blame is clear - it HAS to be us.  

Or maybe an older version of our software was working correctly.  You install the newer version.  When you do that, the order of this 'chain of programs' changes.  Maybe we were 12th, now we are 5th.  Maybe we are now 15th.  This change of order allows a previous bug outside of our software to get TO us.  Maybe we are to blame.  You uninstall the new version and re-install the old.  Maybe we go back to being #12.  Maybe we go in as 13 and it's 14 that has the issue.  Things work again.  For you the blame is clear again:  .16 works, .24 doesn't.  24 is to blame.

But not so fast.  Now we take the report and we start looking for commonalities and differences.  It usually only takes us 1 report of a REPEATABLE issue, or 2 of the same issue that is non-repeatable to figure out where a problem is in our code.  if you say 'I do this, then this, then this and this wrong thing happens' - we take that, duplicate it, and can find the issue.  If two or more people report an issue we find what is in common and can find the problem that way.  But sometimes our software will experience the symptoms but the cause is far outside our reach.

Before dropping the blame bomb, please consider that it is very possible that it really is something outside of our control.  I know many are used to blame shifting when dealing with other companies, but we don't do that.  Please DO keep collecting data and letting us know what is happening.  Even if it's not a problem with our code, if we can work around something we will.  If we can figure out what is wrong, we will let you know.

---

JR, I found your ticket and read through it.  I doubt your issue is the same since you seem to be having problems with the mfg of the computer and your upgrade to Windows 10 which was not supported.  We have your ticket and it is still open, but the root cause still seems to be that your computer is not compatible with Windows 10, or something outside of our software (like above).  Your ticket is still open to see if we can find a resolution for you, however what you reported has not synced up with any other issues people are having.

 

[Kyle Whitaker]

DevMike,

Makes perfect sense, my history shows that LOR is always truthful, extremely helpful, and professional.  Now that it has been verified that it doesn't seem to be an LOR issue I am reloading the PC back to it's original configuration and hopefully everything will run smooth again.  I have no doubt that the problem is on the "Windows side".  

Thank you,

Kyle

 

[dibblejr]

1 hour ago, DevMike said:

I replied to your ticket.  The issue is outside of our software if the faulting module is that ATI dll.  If the faulting module path is 'Unknown' then that is within Windows itself.

As for the comments about .16/etc being more stable, you will want to look outside our software for any changes you may have made to your computer.  There have been no changes that would create any of the issues you are seeing (like the audio file problem or Monitor/Listener/etc crashing).  The only changes between 16 and 24 were in the hardware utility, Superstar and SD card creation.  There was a single bug in the SE that would only come up if you used insert device for a pixie.  You can verify that yourself by looking at the what's new page.

I know many of you won't believe this (as previous history would suggest).  Please remember that a computer (or software) does not run in a neat little box.  Many things are inter-related - even things you THINK are not related can be.  When things stop working that were working, you need to look at what changed.  Since I have access to the code, I can see what changed on our end.   

I checked the last time we made any change to the listener and it was for version 4.3.6.  That was 20 months ago, and it was only for MBCS computers (like Japanese language):

Revision 15703 - Directory Listing 
Modified Tue Mar 8 21:20:05 2016 UTC (19 months, 3 weeks ago) by bob 
Original Path: trunk/LORCommListener
VB interface to the Comm Listener wasn't behaving well under Japanese systems (and assumedly other multibyte systems).

The change before that was more than 2 years ago and only to the icons.

Revision 15124 - (view) (annotate) - [select for diffs] 
Modified Sun Oct 4 21:01:12 2015 UTC (2 years ago) by bob 
Original Path: trunk/LORCommListener/LORCommListener.rc 
New main app icons used by VB6 stuff and the Comm Listener.

The last change to LORMontior (which encompasses LORtray as well as the show player/etc) was a year ago.  That is the one that was correctly identified as fixing an issue with video playback in 4.3.16:

Revision 16106 - (view) (annotate) - [select for diffs] 
Modified Wed Oct 26 18:07:27 2016 UTC (12 months ago) by MattBrown 
File length: 79525 byte(s) 
Fix for video playback in V4 show player.

The totality of that fix was changing 1 line:

If NewState = wmposMediaOpen Then - old        
If NewState = wmppsPlaying Then - new

I looked at that entire module.  Even if that is still not right, it does not lead to any race condition or crash.  The worst that can happen is a video window that pops up when it shouldn't, or a video window doesn't pop up when it should.

Even more important is that all that code has already gone through 1 full season.  If there were issues with it, they would most certainly popped up last year.  We are very good at identifying patterns and we haven't seen any.

The fact that a different computer runs our software fine pretty much tells you were the problem is:  the computer.  Our code would be identical between the 2 machines, so what is different is where the issue is.  And when we say 'There is an issue with the computer', that issue is most likely operating system or software you installed.  RARELY is it hardware related.

What many of you don't understand is that installing ANY piece of software on your computer can modify the way Windows operates.  That is the power of Windows and why we can write neat things like the LOR software.  The problem is that there is a ripple effect - if one of those doesn't quite deal with something in the chain correctly, that can cause problems outside of that code.  More worse:  Sometimes it takes just the right combination of programs to cause a problem.  Worst:  Maybe it's the ORDER they were installed in!

So for example, you use 'Program X' a lot.  So you install 'Program X' on every computer you have.  Program X however has an issue where it may not expect a perfectly legal value for something in Windows.  It throws a fit, and we get something completely out of whack.  We use that for another operation and whammo.  Things die.  Every computer you own breaks our software.  For you the blame is clear - it HAS to be us.  

Or maybe an older version of our software was working correctly.  You install the newer version.  When you do that, the order of this 'chain of programs' changes.  Maybe we were 12th, now we are 5th.  Maybe we are now 15th.  This change of order allows a previous bug outside of our software to get TO us.  Maybe we are to blame.  You uninstall the new version and re-install the old.  Maybe we go back to being #12.  Maybe we go in as 13 and it's 14 that has the issue.  Things work again.  For you the blame is clear again:  .16 works, .24 doesn't.  24 is to blame.

But not so fast.  Now we take the report and we start looking for commonalities and differences.  It usually only takes us 1 report of a REPEATABLE issue, or 2 of the same issue that is non-repeatable to figure out where a problem is in our code.  if you say 'I do this, then this, then this and this wrong thing happens' - we take that, duplicate it, and can find the issue.  If two or more people report an issue we find what is in common and can find the problem that way.  But sometimes our software will experience the symptoms but the cause is far outside our reach.

Before dropping the blame bomb, please consider that it is very possible that it really is something outside of our control.  I know many are used to blame shifting when dealing with other companies, but we don't do that.  Please DO keep collecting data and letting us know what is happening.  Even if it's not a problem with our code, if we can work around something we will.  If we can figure out what is wrong, we will let you know.

---

JR, I found your ticket and read through it.  I doubt your issue is the same since you seem to be having problems with the mfg of the computer and your upgrade to Windows 10 which was not supported.  We have your ticket and it is still open, but the root cause still seems to be that your computer is not compatible with Windows 10, or something outside of our software (like above).  Your ticket is still open to see if we can find a resolution for you, however what you reported has not synced up with any other issues people are having.

 

Mike,

Was going to reply by explaining yet again but I will await my once again brand new gaming laptop that will only get 4.3.18 which brings me to another question and be dedicated to show only.

All computers came with windows 10 and have functioned while sequencing until 4.3.24 about a month ago. Except for the small problem below. I don't know where the statement "I'm having problems with the computer mfg" I never said that anyplace. They have been cooperative.

What happens when the "max" number of downloads occur. #6 for me.

You know I am an LOR fan and just hope there is a positive outcome.

As far as no one else reporting the issues, keep in mind it always starts with 1 and I seem to have that luck. 3 computers with the same results. My laptop has started experiencing a lot of SE crashes while sequencing faces. I am contributing this to remanufactured music since that normally is the common denominator. The old music or new music that is digitally re mastered. Just freezes after some time warp movements. This was a very old ticket for me but has continued, ive gotten used to it.

It does no good for anyone to get upset and that is not the kind of person I am. Just hoping the information can assist LOR if it does happen to be a small bug somewhere.

JR

 

[DevMike]

When you hit max installs you'll get a message that you are out of seats.  A quick ticket will get you more.  

I checked your license (under your eMail associated to your forum account) and you are still good for several more installs.

[k6ccc]

JR, no problem on the max number of seats.  Open a help desk ticket and advise that you have replaced a computer with LOR software with a new computer and they will fix it for you.  I normally list what I have CURRENTLY “ in service.  For example (likely more information than needed):

Family Room - Win 7 - primary sequencing PC

Old show - Win XP - being replaced

New Show - Win 7 - new show PC

Server - Win Server 2012r2 - file server and show player during non-Christmas season

Laptop - Win 7 - occasional sequencing PC

Old work desktop - Win XP - primarily used for testing stuff to make sure it works on XP (testing S5 on that one)  

 

 

 

[dibblejr]

1 hour ago, DevMike said:

When you hit max installs you'll get a message that you are out of seats.  A quick ticket will get you more.  

I checked your license (under your eMail associated to your forum account) and you are still good for several more installs.

Thank you, had been thinking about that since I ordered the new computer.

We are all good. Like the thread on how to handle problems and how to address people. Its the only way, tempers never win, most of us are Alpha males.

JR

[dibblejr]

1 hour ago, k6ccc said:

JR, no problem on the max number of seats.  Open a help desk ticket and advise that you have replaced a computer with LOR software with a new computer and they will fix it for you.  I normally list what I have CURRENTLY “ in service.  For example (likely more information than needed):

Family Room - Win 7 - primary sequencing PC

Old show - Win XP - being replaced

New Show - Win 7 - new show PC

Server - Win Server 2012r2 - file server and show player during non-Christmas season

Laptop - Win 7 - occasional sequencing PC

Old work desktop - Win XP - primarily used for testing stuff to make sure it works on XP (testing S5 on that one)  

 

 

 

Thanks Jim. Based on DevMikes reply I am thinking it goes by upgrade or something because I would be above the 5 as posted. I am sure though if needed they are aware of my computer/ SE issues and why I had so many.

JR

[Kyle Whitaker]

JR - I hope not to jinx myself but I reloaded the laptop back to the factory defaults and it's been running without an issue for more than 24 hours now using v4.3.24.  I let Windows install it's updates (quite a bit) but I didn't change/update any of the other drivers that are loaded such as video, sound, etc.  Quite a bit of work to reload it but worth it if it keeps running.  I will let is run the schedule for another week or so before stamping 100% solved on this.  I'm not sure if you have tried a complete restore and reinstall on your show computer but if you haven't it is worth the time to try.

[DevMike]

Please keep us informed as well.

And thanks for listening.  Really, we don't like to blame shift around here and we really do own up to our mistakes.  4.3.18, 4.3.20. 4.3.22 and 4.3.24 were all due to bugs that your's truly introduced, so I am not immune to making mistakes.

In fact, I'll tell you the long and boring story about 4.3.24...  In 4.3.20 and 4.3.22 I worked to increase the speed of testing Pixel devices in the hardware utility.  If you tried to test a CCD device before 4.3.20, you would see that the test would go 'up the string' -- As in each individual pixel would light one after the other.  That is great for 50 pixels, but for 100 it starts to get old.  Throw a Pixie16 or Pixcon16 into the mix and it's even slower.

There are multiple different ways our software can send to our devices.  Previous testing in the HWU used something called 'non-blocking'.  That is, every time I sent a command that command was immediately sent out over the wire.  The 4.3.22 version used 'blocking' - I would batch together commands until I told it to send.  By doing that, the data stream can be compressed and any overhead only happens once for the string, not once each pixel.

So in 4.3.20 I put in the foundation in for that, along with the changes for making testing easier.  I didn't activate all of it at that time since I wanted to make sure I didn't break anything.  Everything worked well.

In 4.3.22 I turned on the blocking and it worked great, but unknown to me I had broke something else badly.  None of my tests showed an issue, but within a few hours of releasing 4.3.22 we had two reports that Hardware Utility was randomly not finding controllers.  Nothing I did should have had an effect on the 'refresh' button.  With the first report it went on my radar, but again it could be anything.  When the second report came in, I knew there was an issue.

Regardless of how sure I was that I didn't cause an issue, here are 2 people that are reporting identical problems, AND where they are reporting the problem there was a recent change.  When something goes wrong what changed MUST be the problem.  I will tell you right now I was no where NEAR the code that did the refresh, but my experience and knowledge tell me I did something wrong.   

There is something in common between testing and doing a refresh - both use communications.  Uh oh.

I had the release pulled until I could see what happened.  It took me a while but sure enough I found a set of conditions that involved using the test function and having it screw up the heart beat processing, which screwed up the refresh.  4.3.24 was born, with a but a single one line change in the hardware utility.

Which leads me to another way we diagnose issues that pop up between versions.  Like you saw above, we can look at the history of any file (or group of files) along with the comments a programmer made when sending that change in.  It's called 'Source Code Control'.  But not only can we see what changed, when and by whom,  we can  also see the actual change.  Not only that, we can 'play' the source code forwards or backwards and see exactly what changed at any point in time.

The root cause of the issue in 4.3.22 was NOT a change in 4.3.22.  It was actually a change in 4.3.20.  Remember in 4.3.20 I had started getting the foundation in place.  4.3.20 had the bad code as well - and in fact it was running!  However because I had not fully activated it, something else was coming along and fixing my problem before it actually caused a problem.

So in 4.3.22 I had found the issue, and developed a fix for it.  But I still had more work to do - I still needed to track down where this change occurred, figure out WHY it occurred, and make sure that the fix didn't break some other part.  This is where the source code control system pays.  I told it to compare 4.3.22 and 4.3.20 and show me all the differences (we call it 'a diff').  Then I told it to give me a copy of the HWU just as it was compiled for 4.3.20.  I ran my scenario and could see how things were fixing themselves.  So now I pulled a diff from 4.3.20 to a previous version, and a copy of HWU as it was. Ahhhh...  There is no fixing itself because the bad code doesn't exist here yet. 

4.3.18 and below will NOT have the issue at all - the bad code doesn't exist until after 4.3.18.
4.3.20 has the issue, BUT it self-corrects itself
4.3.22 is broken

That's the one thing we have that end users don't have - access to changes.  One of the very first things we do when someone reports a NEW problem is look at how and when that program changed.  We are reasonably sure the issue is not our code if our code hasn't had a recent change.  I did say 'reasonably sure', and not 'absolutely sure'.  Yes, we still to this day have people report bugs that we can trace back to code written 10-15 years ago!