[bug?] memory leak in MSI Afterburner 4.4.0 final

Discussion in 'MSI AfterBurner Overclock Application Discussion' started by arbys, Nov 12, 2017.

  1. arbys

    arbys New Member

    Messages:
    2
    Likes Received:
    0
    GPU:
    2x Sapphire R9 Fury
    Hello,

    I tried to report this bug here: https://forums.guru3d.com/threads/msi-afterburner-bug-report-suggestion.305901/ but the thread is locked.

    I'm experiencing a memory leak issue in MSI Afterburner 4.4.0 final:

    [​IMG]

    restarting the application and rebooting my system doesn't help, Afterburner will eventually gives me the "out of memory" error message.

    System configuration:
    Windows 10 Fall Creator Update
    AMD Crimson Relive 17.10.2
    2 x Sapphire R9 Fury Tri-X in Crossfire
    RTSS v 7.0.0 (bundled with Afterburner 4.4.0 final)

    I'm using RivaTuner OSD, the built-in MSI tech skin and a fan curve profile, the rest of my settings in Afterburner are:

    [​IMG]

    [​IMG]
     
    Last edited: Nov 12, 2017
  2. JonasBeckman

    JonasBeckman Ancient Guru

    Messages:
    13,524
    Likes Received:
    143
    GPU:
    Sapphire R9 Fury OC
    Might be possible to use something like process monitor or process explorer from Sysinternals (Now part of Microsoft.) to further monitor what's going on, interesting to see it being Afterburner and not Rivatuner so I wonder what's going on but I guess toggling settings and seeing how it affects memory usage might also be one way to find which setting(s) are affect this, might require a restart of Afterburner if you disable hardware control though.
    (Checking what's reading or writing to memory I mean, perhaps it's a bit much though if you can find the setting causing it.)

    EDIT: If you upgraded from a earlier version of MSI Afterburner or Rivatuner then deleting the existing user config file(s) might also help ensure it's not some setting that is acting up by having it using a default config for starter and then re-customize it from there, if you uninstalled it first though that should have taken the config files as well so then this isn't of much use.


    EDIT: Mostly just some simpler advice, could even be a driver issue in the worst case, guessing you're remaining on 17.10.2 instead of 17.10.3 or 17.11.1 for a reason. :)
     
  3. cj7109

    cj7109 New Member

    Messages:
    1
    Likes Received:
    0
    GPU:
    Dual R9 Fury X
    FWIW, I'm seeing this as well on 2 systems. One a Ryzen 1800+ with Fury X and an FX8150 with Fury X. Happened on drivers 17.10.2, 17.10.3, and 17.11.1, even after a fresh (clean) installation of the drivers and Afterburner.

    Edit: Forgot to mention that my installation was Afterburner only, no Rivatuner.
     
    Last edited: Nov 14, 2017 at 6:14 AM
  4. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    13,177
    Likes Received:
    208
    I'm afraid that I cannot reproduce and confirm a leak on any of my AMD (both single GPU and Crossfire platforms) or NVIDIA PCs, sorry.
     

  5. arbys

    arbys New Member

    Messages:
    2
    Likes Received:
    0
    GPU:
    2x Sapphire R9 Fury
    Its still happening after uninstalling 17.10.2 in safe mode using DDU and upgrading to 17.11.1. I also uninstalled MSI Afterburner and I deleted the config files before reinstalling it. I'm using the default Rivatuner configuration.

    It happened 3 times since (boot time): 2017-11-12 5:17:54 PM and ~10hrs of gaming w/ RTSS.

    [​IMG]

    [​IMG]

    voltage settings:
    [​IMG]

    modified crimson settings:

    [​IMG]

    and here is what I'm displaying using RTSS:

    [​IMG]
     
    Last edited: Nov 15, 2017 at 2:55 AM
  6. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    13,177
    Likes Received:
    208
    Still cannot make it leak memory on any AMD/NV test PC here, sorry. I'm afraid it is either Fiji specific bug inside AMD ADL API or some third party application injecting hooks into AB process.
    If I were you I'd try to monitor the process memory usage increase dynamics since startup to see which settings exactly affecting it. When doing that keep in mind that monitoring history buffer can fit up to 3600 data samples (up to one hour of monitoring data history with default 1000ms polling rate) so it is expected to see process memory usage growing up slowly till filling whole monitoring history buffer, so it is expected for application memory usage to be slowly increasing from initial approximately 15MB to 20+MB (when minimized to tray, open skinned GUI will add a few MB more) with full monitoring history buffer. You may speed up the process of filling monitoring data buffer by setting polling rate to minimum 100ms. So it will be full in approximately 6 minutes.
     

Share This Page