Microstation Connect Edition 10.0.0 is not generating Exception logs or minidumps, how can I resolve that?

Hi Mark,

Mark Schmidt said:

Microstation Connect Edition 10.0.0 is not generating

Does the user really use version 10.0.0? MicroStation users 4 digits numbering system, so I guess it's 10.00.00.25 (can be shortened to 10.0.0.25).

When this version is really used, it's seriously old version, not recommended to use today. It was the first CONNECT Edition version, released nearly 5 years ago! As you can imagine, the first version are not very good usually and MicroStation was not different. Today CE Update 14 (build 10.14.01.109) is much better (in fact, it's probably the first version fast and stable enough to be used in more complex projects).

Mark Schmidt said:

I see that MS can generate both minidumps and exception logs

Yes, MicroStation creates these two files when (A) anything goes wrong and (B) MicroStation is still in a condition to create the logs.

Mark Schmidt said:

Does MS need to be configured to create those logs/files and if so how do you do it?

No, MicroStation is configured to produce logs by default. But when more detail logging is required, the variables mentioned by Bob Rayner can be used.

Mark Schmidt said:

when it came back up the file she had been working on was gone

I guess exception log and minidumps will not help too much in this case, because it sounds more like Windows issue than MicroStation problem. Especially when machine hard reset was necessary and not simple "kill MicroStation".

Did you check Windows logs, whether anything was reported by operating system?

Mark Schmidt said:

resulted in nothing found.

When crash is serious (MicroStation is too corrupted to create logs or the crash is caused by Windows), the log and minidump are not created. It's quite rare situation, but can happen.

When MicroStation hangs (the process still exists) but Windows still lives, in addition to procedure described in wiki (in Andrew Bell) you can create minidump from Task Manager:

1. Start Task Manager (Ctrl+Shift+Esc, Ctrl+Alt+Del and choose Task Manager, or start taskmgr.exe).
2. Find MicroStation in the list of processes.
3. In mouse context menu (right click on MicroStation process), choose Create Dump file.

With regards,

  Jan

Does the user really use version 10.0.0? MicroStation users 4 digits numbering system, so I guess it's 10.00.00.25 (can be shortened to 10.0.0.25).

When this version is really used, it's seriously old version, not recommended to use today. It was the first CONNECT Edition version, released nearly 5 years ago! As you can imagine, the first version are not very good usually and MicroStation was not different. Today CE Update 14 (build 10.14.01.109) is much better (in fact, it's probably the first version fast and stable enough to be used in more complex projects).

No sorry, the full version for this user is 10.08.00.37. The highest we have in use is 10.12.00.40 update 12. Apparently I'm told the last time they tried the latest version (back in 2018) that it broke TopoDOT so they downgraded just a smidge. I will see about getting someone to test 10.14.

No, MicroStation is configured to produce logs by default. But when more detail logging is required, the variables mentioned by Bob Rayner can be used.

I assume the typical log location is in the users AppData yes?

I guess exception log and minidumps will not help too much in this case, because it sounds more like Windows issue than MicroStation problem. Especially when machine hard reset was necessary and not simple "kill MicroStation".

Did you check Windows logs, whether anything was reported by operating system?

I'd normally agree but I have seen applications lock the host OS up before.. as resource hungry as MS can be I would not surprise me if that's what happened.  But I only have what the user says happened to go on since they are WFH right now. The event viewer was useless.. had nothing related to what happened. 

When MicroStation hangs (the process still exists) but Windows still lives, in addition to procedure described in wiki (in Andrew Bell) you can create minidump from Task Manager:

1. Start Task Manager (Ctrl+Shift+Esc, Ctrl+Alt+Del and choose Task Manager, or start taskmgr.exe).
2. Find MicroStation in the list of processes.
3. In mouse context menu (right click on MicroStation process), choose Create Dump file.

You know all these years and I've never even tried the Create Dump File to see what happens lol. I'll definitely give that a go next time!

Mark Schmidt said:

I assume the typical log location is in the users AppData yes?

Yes.

The most simple way how to find the location is to use $ % explorer $(MS_TMP) key-in in MicroStation. It opens Windows Explorer in the that folder (temp).

Mark Schmidt said:

as resource hungry as MS can be I would not surprise me if that's what happened.

MicroStation is not so hungry application (when compared with its functionality). For 2D and average 3D files, e.g. memory consumption is less than e.g. Chrome or Firefox ;-)

Mark Schmidt said:

I have seen applications lock the host OS up before

It should be very rare situation. I have not seen it for years (and when, it was about HW or driver problem). Halted / locked application yes, but whole Windows? But of course, it can happen.

Mark Schmidt said:

I've never even tried the Create Dump File to see what happens

Well, memory dump is useful for the application developer, but for nobody else ;-)

Its usefulness is also based on what caused the crash and what type of dump (from minidump to full dump) is created. Sometimes the problem is seen easily, sometimes it requires detail analysis.

There are not many application that are able to handle memory dump, probably the best is WinDbg available from Microsoft Store. Even when it's named as Preview, it's better and more user friendly than standard tools available e.g. in Windows SDK.

Regards,

  Jan

yup.. I've used WinDbg in the past for reading Windows dumps. I mean yeah it's not typically helpful since 90% of teh time a Windows dump is caused by NToskernel but occasionally there's some other file responsible. 

yup.. I've used WinDbg in the past for reading Windows dumps. I mean yeah it's not typically helpful since 90% of teh time a Windows dump is caused by NToskernel but occasionally there's some other file responsible.