i have a lot of events listed in the reliability report related to Directory Opus. I have noticed that I get strange listed redrawing and a general slow down of DO. I have to kill the process with task manager to clear the 'slowness'. I have also had several BSODs. Not saying they are related, but I don't get the BSODs as often if DO is not running.
I am running latest version of DO, i think, at 12.21.
Comments and suggestions welcomed. I enjoy using DO too much to pull the plug, but if this continues, I may have to do it.
Usermode programs like Opus cannot cause a BSOD. Only something at a lower level (kernel, antivirus, drivers, hardware) can do that.
That's especially true if you still get BSOD when Opus isn't running, even if they seem to happen more when it is. You should not get any BSOD at all.
The two may be unrelated, but it's also possible one issue is causing the other. I would focus on getting to the bottom of the BSODs first, and make sure all your drivers are up to date from the manufacturer's website (not just generic ones that come with Windows). (Windows 10 has a nasty habit of replacing working drivers with bad ones, too.)
One place to look is faulty storage hardware; BSODs are often caused by faulty USB drives or even a faulty USB cable. The problems may only show themselves when copying to or from those drives.
If you weren't also seeing BSODs, or want to investigate whether there is a separate Opus-related issue in additon to them, I'd recommend these guides for working out where the problem is coming from (it could be Opus itself, or a shell extension, thubmnailer, viewer etc. something else has installed into the dopus.exe process) and/or sending us crash snapshots which we might be able to use to tell you more:
I have run memory diagnostics and replaced 64GB of ram. two SSD drives and two spinner drives all check out 'ok'. I have swapped video drivers due to the CAD application i support. both BSOD and DO issues persist through all of these diagnostics.
some of the issue seems to depend on how long the system [laptop] has been running between reboots. The system is generally up 24/7. If I have DO running, i can go 2-3 days between boots. If it's not running, I can go 2-3 weeks between boots.
Motherboard and storage (SATA, and USB if relevant) drivers are also highly relevant here.
In the past we've seen BSOD caused by bad motherboard drivers that didn't like the way we updated our progress dialog while a lot of data was being written to disk at the same time. It could be an issue like that. Those issues affected other software as well, but happened more when Opus was copying files, since Opus happened to do something that was likely to trigger the issue. Updating the motherboard/SATA drivers fixed the issue in that case.
If you're seeing BSOD when Opus isn't running, even if you're seeing fewer of them, then there's a deeper problem with the machine than anything Opus itself could be causing.
(There may also be an issue with Opus, if the two things are not related, of course, but I would fix the BSOD first, since it needs fixing either way and may resolve both issues. Fixing BSOD is probably beyond the scope of this forum, but if you can tell us some details about it we may be able to help. BSOD usually have a "stop code" which tells you the nature of the error, and sometimes also point to a particular driver/DLL/SYS file, for example.)
What's memory usage like in Task Manager's Performance tab just after reboot vs after a couple of days? If system memory is being exhausted, that could be causing some of the problems. We have a guide on tracking those down, but it's only worth looking at if it looks like that's the issue:
the last 5 BSODs have all had the same code: 0x1000007e. the associated filenames are FLTMGR.SYS, ntoskrnl.exe, and PTCVFsd.sys
I have been focusing on the BSODs first, but today DO got weird again, and I thought it was time to stop by here and check in.
I am skeptical that running out of memory is the issue, since I have 64GB of ram. I only get close to that limit when I run large simulations, or multiple VMs.
I didn't find any dump files when I initially searched. I force created one just now. I can send that if that helps, but That would be after i killed DO and restarted after the slow redrawing issue today.
Seems to be part of "Windchill Workgroup Manager", a google search turned up this article (you need an account to read it) which sounds like it is about this issue:
i recognize that program, and can read that article. Funny thing is that I am using a much newer version of the wcwgm than is listed in the resolved by date code.
Let's assume that is the source of the BSODs for now. what are the next steps for working the DO issue, if they're not related?
I'd wait to see if solving the BSOD resolves the other problems, though. Filter drivers like PTCVFsd.sys will potentially intercept all disk activity. If they are going wrong, they could cause all sorts of issues.
I will start there. I am surprised to see the issue was resolved in 11.0 M030, and I am running 11.2.1.0
11.0 M030 was released june 2017, and 11.2.1.0 released december 2019.
Thanks for the help in debugging. I will work this on the PTC [software vendor] side. then see what happens in DO.
I won't give up on DO yet. Like I said before, i like it too much!
That doesn't tell us much (and wasn't one of the things we suggested). It only tells us that ntdll.dll (part of Windows) is where the crash is happening (but that probably means something farther up the stack is feeding it invalid arguments, or there's a driver issue, not that ntdll.dll is where the bug is, although that is also possible).
Have you fixed the BSOD issue yet?
Or have you tried uninstalling the Windchill Workgroup Manager which seems to be causing it? If you no longer get BSODs and crashes with that uninstalled, I think it would confirm or disprove the evidence so far (depending on what the BSOD then said, if they still happened; it could just mean the driver is still on the system).
As I mentioned above, I have an open call w/ PTC. I am awaiting their live response, as the call was opened late in the business day yesterday. So, no, that issue is still open.
I only sent the reliability data from today, as it was annoying to find DO totally unresponsive. DO is the only app that shows up in that report, and there are a lot of entries there. I thought you might find something of value in that info. Sorry you didn't.
I am stopping the PTC WFS service until I get live contact with a PTC TS engineer. I will track if / how that influences DO's behavior.
I did send two minidump files to crashdumps@gpsoft.com.au.
Please resolve the BSOD first, else everything else could be a waste of time.
Note that stopping their service may not prevent their driver being loaded. It may mean it does less and doesn't hit the bug, but it could also still run into problems. It may need to be completely uninstalled to test its involvement. (But if it does BSOD again, it should tell you which driver is involved, so you'll know if it's still the same one, of course.)
I've only seen an email asking how to send them so far. If there's a later email it may not have arrived yet. If you need a way to send large files, OneDrive and GoogleDrive both allow sharing large files. If you don't use those, a service like https://wetransfer.com/ can be used without any account.