WinAppDriver leaking memory after April update (1803)

[MioOgbeni]

Hi, in our company we're using WinAppDriver for stress testing our UWP application. Its mean that ours tests repeatly doing few thing within 24 hours, more precisely its something about 1500-3000 iterations. When this tests runs under Windows version 1709 so its work properly, but under Windows version 1803 we noticed that tests started leaking huge amount of memory.

Our UWP application is taking properly someting about 120-250MB.

Comparation:

Windows 1709 1500 iterations 64MB start memory 228MB end memory

Windows 1803 3000 interations 70MB start memory 4,5GB end memory (228MB was reached after 60 iterrations)

We noticed that memory is holded by our application (says task manager), but all of this leaked memory is released after closing WinAppDriver, and after this is application properly running only with max 250MB of memory.

Can you help us to find problem, please?

Here're two xlsx with stats. Win1803.xlsx Win1709.xlsx

BTW: When we tests this by manual, than everything is working properly, but by hand we was able to do only something about 150 iterations (more iterations is too much work for me).

[khouzam]

Hi @MioOgbeni,

Thanks for reporting this issue. I'll take a look and see if I can reproduce the issue. There might have been a change in the OS that is causing memory not to be released in the same way. I'll report back any findings but might need your help in setting up a proper scenario.

Thanks

[MioOgbeni]

Thanks, If you will have some questions about scenario, let's ask me.

[rajeeshmenoth]

Hi @MioOgbeni Could you please share how you obtained the memory usage information? Did you use some kind of a monitor to record memory usage?

Thanks

[MioOgbeni]

We measure this only by Windows task manager.

[khouzam]

Hi @MioOgbeni

I do see a slight increase on build 17134.165 compared to 16299.492 running the alarm clock tests. But nowhere near the difference that you're seeing. After 100 iterations we're at 300MB and 215MB for each.

Can you check if you are closing your sessions after each run, you might be causing WinAppDriver to keep the Accessibility tree alive if it keeps running but your sessions is not closed or released.

Would you be able to share some of the details privately of your runs?

[MioOgbeni]

Hi @khouzam I'm closing session after test, but in this test is 3000 iterations of login/logout in our app. It's only few press of button in each iteration.

I need to test that our app don't leaking memory, but when I will close session after each iteration that session close also our app and release memory.

I can try this if there are some nocloseapp capabilities or some session close function which don't close app.

[hassanuz]

Thanks @MioOgbeni. Let us know what you get back with.

[MioOgbeni]

@hassanuz I said "if there are some", but I think that there aren't. All of session closing functions (Dispose, Close, Quit, etc..) close also my app. Or not? Can you clarify it?

[hassanuz]

Hi @MioOgbeni,

Sorry for the delayed response - can you let us know if you're still facing this memory leak? Is it possible for you try the newest Windows 10 build (1809)?

Thanks

[ghost]

I am facing similar issues. If i do the task manually, i do have a leak, but the leak seems to be significant with automation using the windows application driver.

I will try to check with the latest windows build...

[AllSparkler]

@mr-aditya Don't bother trying with different builds! our testing saw a few functions of this framework (Find*xx) definitely show a leak. @hassanuz we tried rolling back and changing to newer builds, but it hasn't made a difference

@MioOgbeni Were you able to overcome or find a workaround to this problem?

[pradeepkumar-devaraj]

Is there any update on how to get rid of the memory leak issue? @mr-aditya Did you get any solution for this problem. Please let us know.

[mvw684]

Hi,

At my company we also tried winappdriver for some accelerated life time testing. We see clear memory leaks after some 50 iterations.

What we noticed when analyzing dumps is that leaks are related to automation peers, and, according scitech memory profiler, related to reference counted GCHandles. Exact same issues we observe when using coded UI from Microsoft, both CodedUi and appium WinAppdriver appear to eb using same cross process infrastructure to cummunicate with the automation peers.

Maybe that is related to the flow in this issue ( we noticed this after a more recent, the 1903 windows update, though we are on the LTSB/LTSC branches of windows 10)

Regards, Mark

[mvw684]

I hope the image upload succeeded Note that according scitech memory profiler many of these refcounted GCHandles had a refcount of zero, and despite aggressive GC2 execution these persisted.

Regards, Mark

[Jingru5]

We are still seeing this issue, when the WPF application initially launched, it consumes ~163MB of memory; After 60 tests run, the memory consumption raised to 1210.5MB.

[ashkaps]

@hassanuz we are also experiencing the same issue with our app. Subsequent "driver" operations keeps increasing memory usage. Was a fix was ever identified for this?

[mvw684]

@ashkaps We have opened a case with Microsoft, a few weeks ago, which is not yet resolved. We recently did a simple experiment, run our app with Narrator active. As Narrator uses same automation peers we were expecting same behavior. However, with Narrator we see a leak on the 2016 LTSB version and no leak on the 2019 LTSC. So at this point we are slightly confused.

Note that we are running on 64 bit OS and we use 32 bit mstest to run coded UI or WimAppDriver. I assume Narrator is a 64 bit process (did not check those aspects yet.

[Smurph007]

@mvw684 Can you let me know the ticket ID for this issue at Microsoft, that I'am able to track some improvements on this very nasty behaviour? Thx a lot.

[mvw684]

@Smurph007 our case number: REG:120031123002339 Feel free to reach out in case of further questions