- ago
I'm seeing that if WL8 is left open with no streaming, no running SM, nothing running then WL8 will still sip about 20% of CPU all the time. I left WL8 open overnight, and it caused my PC to become very hot.



I looked into the threads it is running and I found wpfgfx_cor3.dll is the main CPU user


When WL8 window is minimized only then CPU consumption goes down and it is no longer running wpfgfx_cor3.dll


Do you think it can be optimized to save CPU when nothing is being run on WL8?
0
429
20 Answers

Reply

Bookmark

Sort
- ago
#1
I don't think so, it's really not anything WL is doing itself, it's just the WPF framework here.
0
- ago
#2
Also I think it doesn't look like what I experience, for example after running streaming charts for a few hours solid here is my CPU:

0
Cone7
- ago
#3
3% for me too.
0
- ago
#4
I have a fanless PC (meaning, no active cooling at all; just a passive case made of a big chunk of aluminium). I run it 24/7 and most of the times WL8 is open; some times running the Evolver for multiple days non-stop; and yet, I also don't experience that behaviour at all. I have WL8 open since this morning; and just been looking at the resource consumption for the last 10m: around 0.1% CPU, 0.2% GPU (integrated in my case) and 312MB RAM. Nothing special...

I do keep Windows (11 in my case) and any C# related framework (.NET Framework and .NET Core) always very up to date. You could try to see if you are running the latest versions of the runtime.
0
- ago
#5
Also Andy, it might help to know what you were doing prior to leaving WL8, which streaming provider, etc. Maybe there's a disconnected websocket or something that's causing this at your end.
0
- ago
#6
Clearly you have a WPF window sucking CPU time. It's even sucking GPU time according to your screenshot, so it's definitely a window causing the problem. But you never told us which window is the culprit so we can't troubleshoot it. Help us help you. Start closing child windows until the CPU time drops and report which child window is running without cause.

Also this runaway window might be from one of the WL extensions (and one of its windows). I would start uninstalling the extensions until the problem goes away.

Finally, I would see if there's an update to your video drivers for Windows 11 since they are directly involved. There maybe a bug in the video driver, but you need to determine which WPF call is leading to the video driver not returning control back to the OS like it should before you can report it to the video card manufacture.

Can you confirm this is not a problem with WL7 on the same machine?

As you can see from my screenshot below, my workstation doesn't have this runaway video problem (but it's not Windows 11 either). I'm running .NET 6.0.4 for x64 Client and WL8 Build 5.
0
- ago
#7
Thanks for the suggestions. I have the 5 windows open:
- Two C# coded strategy windows. No streaming. I used the window to backtest the strategy during intraday - looked at bar chart and symbol equity chart.
- SM window open with strategies not running (deactivated)
- Order manager window and
- WL8 Home Page

The WPF thread is always in Running mode. Based on Superticker's suggestion, I did the following:

- On closing one of the C# coded strategy windows, the WPF thread went to Wait:WrLpcReply mode and CPU usage drop from 15% to around 8%.



- One closing 2nd C# coded strategy window, CPU usage dropped to 3-5% range.
- After closing the SM and Order Manager window, CPU usage remained the same
- The last window left is the WL8 Home Page, after closing this, the CPU usage dropped to < 0.01. It looks like the flashing version mismatch on the home page is the culprit.



I did the following now:
- I reopened the saved workspace - with SM, OM and WL8 home page windows open, CPU usage is back in continuous 5% range as expected. GPU usage is 1%
- If I minimize the home page, then CPU and GPU usage is < 0.01.
- When I opened one C# coded strategy window, nothing happens. No chart is loaded
- After backtesting it and loading the chart, CPU and GPU is around 2-3%
- After opening 2nd C# coded strategy window, backtesting it and loading the chart, CPU usage is 5%, GPU usage is still 2-3%.
- After restoring the WL8 home page, CPU usage is 10%, GPU usage is 3-4%
- When I loaded the Symbol Equity chart under Backtest results in the strategy window, then CPU usage is 13% and WPF is now in Running mode. GPU usage is around 10%
- Loading Symbol Equity chart of 2nd strategy, then CPU is back to 15%. GPU usage is also 17%.

It looks like combination of strategy window charts and WL8 home page is causing the CPU usage. Symbol Equity chart causes increased GPU usage. If there is no streaming or no active running strategies, then I think the CPU/GPU usage should decline after chart has been loaded and left open but idle.
0
- ago
#8
There are many elements in the Strategy window, including some potentially animated ones, so I think the modest idle CPU is not something we'll be able to do anything about. Best practice is of course closing WL8 before retiring for the night.
0
- ago
#9
QUOTE:
On closing one of the C# coded strategy windows, the WPF thread went to Wait:WrLpcReply mode and CPU usage drop from 15% to around 8%.

Generally speaking, the WPF thread should be in some kind of wait state. If it's not, that doesn't sound right. But do appreciate any animation "may" bring it out of that wait state.

I'm afraid the failure of the WPF thread to return to its wait state may be a video driver problem. We typically see Windows drivers as being highly optimized. But the exception is with new releases; in this case Windows 11. Understand there is great pressure to get the new product out the door, and since drivers are tough to optimize (especially video drivers), they are the last to get tweaked.

I would go to the video card manufacture's website and update all the video drivers for your system. And I would continue to do that for the next 18 months at least. Also understand, many video card (and computer) manufactures simply "copy" the video driver the video chipset manufacture posts, which would be most up-to-date. So it's "possible" you can download the most up-to-date driver from the video chipset manufacture directly. But I would consult with the video card manufacture first because there could be timing differences between the two implementations.

When the video drivers are fully optimized for Windows 11 (over the next 18 months), the WPF thread should remain in a "wait state" most of the time. Happy computing.
1
- ago
#10
I'm seeing the same issue as the original entry. After loading WL8 my laptop start to run hot and the fans kicks in loud. A few minutes after closing WL8 the laptop fans gets silent and the laptop is much cooler.
The laptop almost never gets hot and I hardly hear the fans. Until I start WL8. After a trading day the laptop is hot!

It would be helpful to find why WL8 (directly or indirectly) is causing this.
1
- ago
#11
QUOTE:
I'm seeing the same issue as the original entry

What version of Windows are you running? Tell us a little more about your video hardware. Most video hardware platforms are not seeing this problem. Does this occur with WL7 or just WL8?
0
- ago
#12
I seriously doubt this is a hardware or OS specific problem superticker... WL8. Windows 11 21H2. AMD Ryzen 7 5700U with Radeon Graphics. 16.0 GB. I rather not going trough this rabbit hole.
This is a software (WL8 and its dependencies) issue. I'll try to use resource monitor to figure out what's going...
0
- ago
#13
QUOTE:
WL8. Windows 11

Well, this is the only configuration combination that's causing this problem. Try installing WL7 on your Windows 11 system and see if the problem goes away. There was a big change between WL7 and WL8 with the WPF video rendering, so if WL7 fixes the problem, that would narrow it down to the new WPF display package WL8 is using to support dark screen mode.

QUOTE:
I'll try to use resource monitor to figure out what's going...

That's an excellent idea. If you look at the original post, you'll see the WPF process is not returning control back to the OS like it should. Status: running. That's a big red flag the video driver is somehow looping--very bad. Even if the application has bugs, the video driver should never be doing that. That video driver needs to be fixed/updated. Nobody else's video driver is doing that.

If the developers can't reproduce the problem, they can't fix the problem. But you already knew that.
0
- ago
#14
I've also noticed high CPU usage in WL8.

Some additional points:
1) The CPU usage is highest when the Chart tab is selected, less with others tabs.

2) I opened 2 identical strategies in WL8, WL7 and WL6.9; only WL8 had this issue.



3) Minimizing the WL8 app or the strategy windows drops the CPU usage to normal (i.e. negligible) levels.

Hope this helps in pinpointing the issue.
0
- ago
#15
I don’t see this as an issue, it’s normal operation.
0
- ago
#16
QUOTE:
2) I opened 2 identical strategies in WL8, WL7 and WL6.9; only WL8 had this issue.

Yes, I kind of figured this might be the case. Can you tell us what video hardware you are running? And is this on Windows 11?

@Glitch: Is the new WPF display package on WL8 using any DirectX calls? If so, I would disable that because the device drivers for DirectX are more problematic. Just avoid DirectX altogether. WL isn't doing any real-time animation, so you don't need DirectX. The "standard" video that uses the standard video drivers will be more reliable.

And Glitch, you're not going to be able to reproduce what they are seeing because you have different video hardware and drivers. (They could send their computer to you.) From what I'm seeing, the problem only shows up on Windows 11 with WL8. Apparently, the WPF display package (on WL8) is making some strange calls the video driver (for Win11) that the driver can't handle correctly. You might contact the author of that WPF package is see if he's seen this problem with some Windows 11 video hardware configurations. He's the one that needs to purse the hardware manufacture about updating the video driver. Happy computing.
0
- ago
#17
We don’t have any control of any kind of “WPF Package”. WPF is part of .NET and the author is Microsoft. WL8 does use .NET6 while WL7 uses .NET3.1.
0
- ago
#18
QUOTE:
We don’t have any control of any kind of “WPF Package”.

I thought WL8 was using a third-party package to implement dark screen mode. So you're saying the only change is from Core 3.1 to .NET 6.0? Well, .NET should just be using standard video calls, not DirectX. Right? So that shouldn't be an issue.

So, bottle line, the .NET 6.0 WPF routines are taxing the Windows 11 video drivers more than Core 3.1 did. That's interesting. (It's actually good because 6.0 is taking advantage of GPU hardware Core 3.1 wasn't doing.) So now the Windows 11 video drivers need to be updated.

The reason I know this is a video driver issue, other than the screenshot given in the original post (which is damming), is because no Windows 10 (or 7) user is experiencing this problem even though they are using the same application code base.

What would be useful is if Windows 11 users would post more about their video hardware, especially the video chipset employed with the problem. The video drivers are tied to that video chipset, so we would be able to identify which video driver is the culprit.

A bad driver can damage hardware, so users should be vigilant about updating new releases of their OS at the device driver level.
0
- ago
#19
@superticker:
1) Windows 10 (latest build)
2) NVIDIA GeForce RTX 2070 video card
0
- ago
#20
QUOTE:
@superticker:
1) Windows 10 (latest build)

That's interesting. A Windows 10 user has this problem. Is it in the WPF routines? Have you updated your video drivers since .NET 6.0 was released? And you're running .NET 6.0.6 (or better)?

I'm running Windows 7 and don't have any problems; I'm running .NET 6.0.6. But my system isn't running the more advanced GPU processors either. At any rate, this is somehow hardware related. With the same application code base, some hardware platforms are more vulnerable than others. However, it's very troubling to learn both Windows 10 and 11 have this problem because they would be using different video device drivers. Moreover, the Windows 10 video drivers would be mature enough to not have a latent bug like this; such a bug would be fixed by now unless .NET 6.0 exposed a new vulnerability.

If this is .NET 6.0.X related--and it seems to be--perhaps a Microsoft TechNet forum may be discussing this WPF issue in better detail.
0

Reply

Bookmark

Sort