PDA

View Full Version : LW 2019 stability



Tim Parsons
04-17-2019, 08:33 PM
Hey everybody I've got a general question about how everybody's experience with 2019's stability has been. My team is getting Layout crashes on the weirdest things. Save image and poof LW disappears. Replace object - poof LW disappears. Save scene - poof LW disappears. When this happens we are not getting notice - it just poofs and LW disappears. I can't be repeated and it is so iffy so there is no sense making a report. Probably happens on average twice during an 8 hr day. Anybody else?

Ma3rk
04-17-2019, 08:58 PM
2019.3 has been quite stable for me & that's with a new system & new OS.

This iss sounding like something else frankly. You say team, so everyone is having issues? Are you all networked with shared assets? Everything you've listed is I/O related.

Kryslin
04-17-2019, 09:28 PM
I've had some bizarre crashes, starting in 2018, and moving into 2019. Usually on closing, sometimes saving something. sometimes loading something. Most are not repeatable, I've tried.

No strange network I/O set ups, just an SSD for boot and apps, and 4TB of RAID storage for data. I'm thinking about setting up a small NAS for data storage, or adding some more USB 3.0 ports and some USB external storage, though, and clearing some of my projects off to there...

omichon
04-18-2019, 01:26 AM
It happens here too while creating a new folder from the File browser when defining a path for output images.
I had this one at least 5 or 6 times, but randomly, so nothing to report unfortunately.

RPSchmidt
04-18-2019, 07:16 AM
Probably a stupid question, but how up to date are the display drivers in your group?

I've found that to be a serious issue with many different pieces of software in my dev group (although not Lightwave so much)... we update to a new version and suddenly we start getting weird crashes.

Then the light bulb goes off and we get on IT to update the display drivers across the systems and everything starts running right again.

If the crashes are at either end of a display driver update (no update or recently updated) that might be the culprit.

OFF
04-18-2019, 07:42 AM
I have another kind of problem - lw 2019.0.3 stops using my hotkey configuration, even many default hotkeys assigned (save, save as) stop working. Selection of more than one object stops working.

RPSchmidt
04-18-2019, 08:15 AM
I have another kind of problem - lw 2019.0.3 stops using my hotkey configuration, even many default hotkeys assigned (save, save as) stop working. Selection of more than one object stops working.

Hey OFF... I see you posted on this issue in the General Support forum.

Perhaps you should start a new topic thread here if you feel that your topic in General Support didn't get enough visibility.

I would encourage you to include some system information in your thread as well; it may help to identify the issue.

Tim Parsons
04-18-2019, 07:13 PM
Probably a stupid question, but how up to date are the display drivers in your group?

I've found that to be a serious issue with many different pieces of software in my dev group (although not Lightwave so much)... we update to a new version and suddenly we start getting weird crashes.

Then the light bulb goes off and we get on IT to update the display drivers across the systems and everything starts running right again.

If the crashes are at either end of a display driver update (no update or recently updated) that might be the culprit.

I need to check the drivers just to make sure as we all have the same hardware. Today it went poof twice when I activated VPR (I use a short cut of F8).

- - - Updated - - -


2019.3 has been quite stable for me & that's with a new system & new OS.

This iss sounding like something else frankly. You say team, so everyone is having issues? Are you all networked with shared assets? Everything you've listed is I/O related.

Yes - we work of a network, but today it went poof when I activated VPR which isn't I/O related. :)

vncnt
04-19-2019, 06:36 AM
Are you using Motionblur? If so, try again without.

Tim Parsons
04-19-2019, 08:59 AM
Are you using Motionblur? If so, try again without.

Not at all. We do product development so its just stills.

Markc
04-19-2019, 10:23 AM
I need to check the drivers just to make sure as we all have the same hardware. Today it went poof twice when I activated VPR (I use a short cut of F8)

When 2018 came out, if I opened an old 2015 scene VPR would crash LW.
A new scene no problem.
I havn’t tried the same thing with 2019.

All seems pretty stable on 2019.0.3 with new assets.

Tim Parsons
04-19-2019, 12:46 PM
When 2018 came out, if I opened an old 2015 scene VPR would crash LW.
A new scene no problem.
I havn’t tried the same thing with 2019.

All seems pretty stable on 2019.0.3 with new assets.

Using all new assets. It just goes "poof" at the strangest times.

MarkAH
04-22-2019, 03:38 PM
Sounds like un-caught exceptions. That can seem totally random even though it's happening in just a few places.
It's totally frazelling figuring out what all exceptions should be handled.
I can't imagine with LW being the mass of plug-ins it consists of.
Tried to figure out just how much of all that stuff is now compiled into dll's by looking at the runtime.
Just gets more confusing.

Sensei
04-22-2019, 03:52 PM
Hey everybody I've got a general question about how everybody's experience with 2019's stability has been. My team is getting Layout crashes on the weirdest things. Save image and poof LW disappears. Replace object - poof LW disappears. Save scene - poof LW disappears. When this happens we are not getting notice - it just poofs and LW disappears. I can't be repeated and it is so iffy so there is no sense making a report. Probably happens on average twice during an 8 hr day. Anybody else?

"Poof and disappear" without any warning or so, is a sign of
1) out of CPU stack (infinite recursion)
2) out of memory (which is easily visible because of heavy disk usage prior it, unless it's also connected with 1) issue..

Perhaps one or couple assets like images that you are using are damaged, and LW I/O loader/saver is unable to handle it, which results in infinite loop/recursion, and voila..


Hey everybody I've got a general question about how everybody's experience with 2019's stability has been.

For me it was very stable so far. Don't remember any crash for months.
But if you use some feature which is buggy, it can make entire app buggy, because of damaged memory (e.g. exceeding boundary of allocated memory or allocated array).
After memory damage (not physically!), not buggy operations can start crashing in unexpected moments.
These issues are the hardest to find, because of randomness of crash, which is not tied to what you actually used/clicked, but typically to freeing memory. e.g. replace asset (object, image, scene) requires freeing existing one, so if memory is damaged, freeing will crash..

Damaged memory can lead to writing incorrect data to disk, and damaging the more assets even more..


My team is getting Layout crashes on the weirdest things.

How many licenses do you have?
Send scene & assets to LW, and it will fixed, if these crashes are so repeatable..

Sensei
04-22-2019, 03:55 PM
Yes - we work of a network, but today it went poof when I activated VPR which isn't I/O related. :)

VPR is (perhaps) using recursion.
On what asset you enabled it? Do you remember?
Even orientation of object on viewport does matter.
If it's reflective/refractive new rays are fired, at perhaps new recursion depth level..

If object is damaged, it could lead to further crashes.

prometheus
04-22-2019, 04:06 PM
I have also had a few of these mysterious, poof..lw disappears or shuts down without any crash warning...not good, I havenīt taken notice of exactly where it happens though..I should, and especially now when more people experience it.
it really did not happen like that in 2015, crashes yes, but not just shutting down in to oblivion.

Tim Parsons
04-22-2019, 07:06 PM
"Poof and disappear" without any warning or so, is a sign of
1) out of CPU stack (infinite recursion)
2) out of memory (which is easily visible because of heavy disk usage prior it, unless it's also connected with 1) issue..

Perhaps one or couple assets like images that you are using are damaged, and LW I/O loader/saver is unable to handle it, which results in infinite loop/recursion, and voila..



For me it was very stable so far. Don't remember any crash for months.
But if you use some feature which is buggy, it can make entire app buggy, because of damaged memory (e.g. exceeding boundary of allocated memory or allocated array).
After memory damage (not physically!), not buggy operations can start crashing in unexpected moments.
These issues are the hardest to find, because of randomness of crash, which is not tied to what you actually used/clicked, but typically to freeing memory. e.g. replace asset (object, image, scene) requires freeing existing one, so if memory is damaged, freeing will crash..

Damaged memory can lead to writing incorrect data to disk, and damaging the more assets even more..



How many licenses do you have?
Send scene & assets to LW, and it will fixed, if these crashes are so repeatable..

Thanks for popping in on this Sensei! Our machines are fairly new (5-6 months) with 64GBs and we aren't close to maxing that out. Maybe using 16 or so. None of us had these weird "poof" it's gone moments with LW2018. I've also experienced this on my home PC which is a completely different setup. If I could reproduce it I would certainly report it. :)

Sensei
04-22-2019, 08:31 PM
Thanks for popping in on this Sensei! Our machines are fairly new (5-6 months) with 64GBs and we aren't close to maxing that out. Maybe using 16 or so. None of us had these weird "poof" it's gone moments with LW2018. I've also experienced this on my home PC which is a completely different setup. If I could reproduce it I would certainly report it. :)

Default CPU stack in Windows PC is 1 MB, regardless of how much is in reality in hardware.

In the case of infinite loop or infinite recursion, there is no way to prevent out of memory, regardless how much do you have installed. infinity > finite number.

Philbert
04-23-2019, 12:54 AM
I actually haven't used Layout in 2019 yet, But I've only had it for 2 weeks. I had modeler crash once due to an LWCad issue. And I've been using it every day.

prometheus
04-23-2019, 01:10 AM
I actually haven't used Layout in 2019 yet, But I've only had it for 2 weeks. I had modeler crash once due to an LWCad issue. And I've been using it every day.

hardly used modeler at all with 2019..its in layout
it happens for me.

Philbert
04-23-2019, 01:59 AM
Yeah I rarely use Layout. Since my main job is modeling I spend my time there. I will be getting into layout when this model is finished next week. I'll be taking advantage of the new sky options. Especially since my scene takes place at dusk and I know the exact location where the building model is located.

Marander
04-23-2019, 04:26 AM
hardly used modeler at all with 2019..its in layout
it happens for me.

Yeah same here, Layout. Not using Modeler or LWCAD anymore, too tedious to work with.

LW 11.6.2 was not that bad but maybe because it was the version I started with and did only simple things with it.

LW2018 and LW2019 are better than LW2015 but overall it looks like the usual LW (in-)stability.

I use LW just for experimental fun so when it crashes too often I tell myself - the devil take it - and try once more or start my main 3d application instead which is rock stable.

MarkAH
04-23-2019, 05:56 AM
This kind of crash, where there is no warning generated, would probably not ever seem to be 'repeatable'.
But I think it would still be logged.
Could be there is a log on the OS Log folder called CBS.log that is a simple text file where, on Windows anyway, a list of events is stored.
Maybe for a month or so.
If you can find that, and include it in a report maybe it will help get the bug fixed.
There might be a tool called Resource Manager that can be run, where you can see the hard page faults.
These would be normally happening, but if it's going out of bounds it should be apparent.
Maybe Sensei could explain better how to do this, what to look for.
Or if it's possible with Windows 10.
I don't run that OS so, not sure if that's available.

RPSchmidt
04-23-2019, 10:04 AM
This kind of crash, where there is no warning generated, would probably not ever seem to be 'repeatable'.
But I think it would still be logged.
Could be there is a log on the OS Log folder called CBS.log that is a simple text file where, on Windows anyway, a list of events is stored.
Maybe for a month or so.
If you can find that, and include it in a report maybe it will help get the bug fixed.
There might be a tool called Resource Manager that can be run, where you can see the hard page faults.
These would be normally happening, but if it's going out of bounds it should be apparent.
Maybe Sensei could explain better how to do this, what to look for.
Or if it's possible with Windows 10.
I don't run that OS so, not sure if that's available.

Event Viewer on Windows will show data on an unexpected application crash.

Run Event Viewer and choose Windows Logs and Application. Then scroll through and see if you can find Layout listed by name or a Windows Error Report that identifies the Event Name as an APPCRASH.

Then click the Event Properties button on the right you can look at the details of the crash.

Best to run Event Viewer right after a crash; that way, it's more likely the Event Viewer report will be one of the first in the list.

prometheus
04-23-2019, 12:04 PM
Yeah same here, Layout. Not using Modeler or LWCAD anymore, too tedious to work with.

LW 11.6.2 was not that bad but maybe because it was the version I started with and did only simple things with it.

LW2018 and LW2019 are better than LW2015 but overall it looks like the usual LW (in-)stability.

I use LW just for experimental fun so when it crashes too often I tell myself - the devil take it - and try once more or start my main 3d application instead which is rock stable.

For the record, Lightwave 11.6.3 has been the most stable version for me... if I compare from Lightwave 10 til 2019, and Lighwave 2015.0.3 has been the worse in terms of stability..with the exception of that I havenīt tried 2019 enough to find
places where it crashes:)

MonroePoteet
04-23-2019, 06:01 PM
For people who have consistent problems with LW2019 crashing (or other applications on Windows), you can install DebugDiag from Microsoft, available here:

https://www.microsoft.com/en-us/download/details.aspx?id=49924

Once it's installed and configured, it monitors the applications you've added to its configuration and produces log files (with a .txt extension) for each invocation. If the process crashes, it will capture a VERY LARGE dump file. For example, here's a screen shot of my current DebugDiag crashdumps folder:

144807

I know what caused the one Layout crash which produced the DMP file (Rman Collection's Marker Pen procedural).

It isn't clear the dump file itself would be useful since it's much too large to upload to NewTek for diagnosis. However, the log (.txt) files produced when a crash occurs contains information that might help LWDG analyze and perhaps fix the problem.

mTp

P.S. if anyone is interested, it appears that the stack entries in the .txt files:


ntdll!RtlLogStackBackTrace+0x284
ntdll!RtlIsDosDeviceName_U+0x94fc
kernel32!HeapFree+0xa

are above the culprit causing the crash. In my Marker Pen crash, the next two stack entries are:


RmanCollect_x64+0x3f53c
RmanCollect_x64+0x10b37


Sorry, Denis! :)

mTp

Sensei
04-23-2019, 06:36 PM
In the case of memory damage, there is no trace of what caused damage in debug log, because it could happen minutes or hours prior crash happened and user noticed it...

Only very obvious ("reproducible") bugs will be in debug log.

wesleycorgi
04-23-2019, 09:37 PM
I just started using Octane. I am curious for those who use Octane, if LW 2019 is more crash prone than previous versions of Lightwave. I am typically crashing a few times per each session.

MonroePoteet
04-24-2019, 08:54 AM
In the case of memory damage, there is no trace of what caused damage in debug log, because it could happen minutes or hours prior crash happened and user noticed it...

Only very obvious ("reproducible") bugs will be in debug log.

Yes, data corruptors are really hard to track down, especially when they corrupt someone else's data. That's one of the key reasons for needing the full DMP file rather than just the stack dump, where the source of the data corruption isn't in the currently executing process / thread. I did o/s level crashdumps for about 10 years, and having an "innocent bystander" crash due to a bug in a kernel-level driver or component (which has write access to *everyone's* memory!) can be very tough if not impossible!

mTp

jwiede
04-27-2019, 01:20 AM
kernel-level driver or component (which has write access to *everyone's* memory!)

That's changing, btw, for most desktop/server OSes. The days of kernel-level entities automatically having access to all memory are largely over, for durability and security reasons -- it's a good thing, and long overdue.

Kernel-level entities can still obtain access if needed (in most cases), but they no longer have unfettered and untracked RW access to all memory by default.