Windows 10 Screen Refresh Issue


We're running runtime version 9.2.4 in a Windows 10 environment, and have run into a strange occurrence where it seems as though a portion of the screen stops updating. We're connecting to the server via thin client, and the application is in use all day long.


The portion of the screen circled here stops updating, while the rest of the screen remains responsive. Once the screen gets in this state, floating windows no longer appear on screen either, though the code is still behaving like they're there. For instance, when subtotaling a transaction we'd pop-up a window that the user has to hit enter or clear on on to proceed, the application waits for the key press like the window is there even though it's not visible, before proceeding. The circled controls are a grid, and a label, nothing out of the ordinary occurs other than the display issues mentioned. Has anyone else experienced an issue like this? Any idea what I should look for here to troubleshoot the issue?





  • Hi Dave,
    You should upgrade to version 10 as 9.2.4 is not supported on Windows 10. I can't say for sure this issue is version related but we need to get you on a supported version ASAP.
  • Hi Doug! Thanks for the suggestion, we received a trial version of 10.2.1, and have gotten the same results. The Thin Client executable appears to be bleeding memory, up until we hit 40-45000kb, then the application falls into this state. I've been trying to troubleshoot the memory leak, but have been unsuccessful so far. My next step is to rebuild our application using 10.2.1 compiler to see if I get some different results, we'd still been running code compiled for version 8.1.3 up to this point.
  • There was a similar bug in 10.2.0 I wonder if they missed the patch for 10.2.1
  • Unlikely that we missed a patch for 10.2.1 (though not impossible).

    To answer the question about getting memory descriptions, you can set environment variables in order to track memory. Do this before starting AcuThin.exe.

    set A_MEM_DESC=3
    set A_MEM_DESC_FILE=\path\to\your\memdesc\file

    AcuThin itself won't execute the code to do the final memory dump, but when acme.dll detects the process ending, it will do that dump itself. I haven't tried this, so this may not be useful.

    If you can use the Task Manager to show AcuThin increasing in memory, you should raise an RPI.

    Finally, recall that there is a difference between a memory leak (we lose the reference, and CANNOT ever release the memory) vs hogging memory (we still have a reference to the memory, but for whatever reason aren't releasing it). The latter may actually be a COBOL issue and not an AcuThin issue. The memdesc report might be able to show which this is.
  • Happy New Year Dave! I'm following up to see if you were able to implement the memory tracing suggested by Randy. If so, did it help? Has the issue been resolved?