After installing the latest release (v1.0.165) on my work computer (windows 10 64-bit), every time I interact with the app my CPU usage spikes for 15-20 seconds. It's most noticeable when I'm entering text into a note or todo, but also occasionally happens when I'm just navigating between notes and notebooks, etc. My work computer has a company image, and I'm wondering if there might be some interaction that is causing this issue? From task manager I see that the process that's using the CPU isn't Joplin itself but rather DgAgent.exe, which I believe is part of a Digital Guardian product that my company uses to prevent data loss/theft via USB and other devices. I only noticed this behavior start after updating to the latest Joplin release, but that could also be a coincidence I suppose.
Has anyone else seen similar behavior or does anyone have any idea as to what might be causing this issue? Thanks in advance for your help.
It’s hard to say, because we don’t know how Digital Guardian works. I would rather ask the company behind this product what triggers a scan or threat analysis. e.g. does it hijack certain system calls and if so, which ones.
Joplin is a react-native app and Electron is used to make it run on desktop. So there are a few layers with communication between them. Editing a note or switching to another note changes the state of variables which are passed between those layers using IPC. This could trigger something in that DG app, but what exactly the app is doing in such a case - I don’t know.
But I’m not a Windows person. Maybe somebody else has experience with this Digital Guard SW.
I am pretty sure that a DG admin can trace what this app is doing and why. If you know someone in your company’s IT department, you should bring this up. Maybe they can help you narrowing down the problem.
From observing recent gh issues and forum topics I can say that there weren’t any that describe CPU spikes on Win after release 165.
Wow, it's such an interesting coincidence that I've found that topic, and that is the only one on the web stating that problem, but apparently, after 2 years, I am also having the exact same problem with my DgAgent(Digital Guardian Agent) on my work computer.
It definitely has nothing to do with Digital Guardian and personally don't think OP had a chance to deactivate it since that is a work computer. And in addition to that Joplin is not the only RN-Electron app that tries to change the state of the variables.
Obvs. there's something wrong with the processes or transaction layers that an AV or client like DgAgent to be triggered and that needs to be addressed. But since looking at the dates of the OP, that is not seems like something will be addressed in the near future...
Please note that there's nothing we can do on our end. No issues without DG, so how do you come to the conclusion it has nothing to do with Digital Guardian? I believe I was rather elaborate in my first reply.
It's the same as blaming Joplin for triggering a false positive in Antivirus SW, which btw already happened a few times.
I think we're looking at the subject from different perspectives. I'm not trying to blame something or any person at all. Accept my apologies if that got you wrong. But it is an existing problem that needs to be resolved rather than blaming things or someone. Someone basically needs to take action on this otherwise users who are mandated to use DG client can't do anything with the Joplin app. It basically invalidates all the cross-platform functionality etc. for the DG mandated users. Does that make more sense now?
So for me, that sounds like "alright guys, our app works smooth without any other apps open, who cares.." "If our app is not working on a 16GB memory, just add 16GB more then!".
What I was trying to say is more like there are millions of apps working flawlessly with DG client without triggering any alarms, so means achieving that is possible. If our(since Joplin is an open source community driven app) app is going on well with the DG client, I think we need to figure out why Joplin triggered that client to do a search. Read the blueprints of DG or talk with DG support as the app owner if it is required to understand the root cause. Don't just let everyone else down with "ok, close the DG client then" words. You're probably not even seeing this as a general problem and is raised on the support forum too much because not everyone can understand that Joplin is hiding behind that CPU spikes of DGAgent. Even not every user will notice DGAgent is behind that CPU spike cause if you do not go into detail it hides behind WMI Provider Host Process.
Anyway, sorry for the wall of words but in general my point is as Joplin we need to take action rather than wait for DG to do something about it or expect users to close DGAgent as that might be mandated for many companies ITs around the world as well.
I think Tessus had a point earlier when he asked if someone contacted DG about this. They might actually care about it and even know that some products don't work well with DG and might have some exclusion list or something to make it work. Basically it's worth trying.
It is theoretically possible that there is something in Joplin (outdated code, not following some little known standard) that is causing the problem.
However, on a practical level, there is really nothing that the Joplin team can do since it involves proprietary software (DG), eh?. And I doubt very much that a security firm like that is going to pay attention to direct inquiries from the makers of a (relatively) little known open source project. It would have to come from customers (like your employer). I doubt even end users like yourself could raise much interest in them. But it's worth a try.
Even the DG support forum is closed to customers only, so that is another limitation.
Moreover, @ugur, the norms of opensource projects are such that, no matter how important the issue is to you, making demands/emphatic requests doesn't get things done.
You may want to create a new thread to lay out the issues you see so far. What you have done to try and trouble shoot, etc. That might be more useful than continuing in a 2 year old thread like this.