Starship Krupa Posted January 28, 2021 Share Posted January 28, 2021 6 hours ago, abacab said: I tried your test with that patch in Chromaphone 3 in CbB, and the memory never changed during the loop. Interesting. You're running the latest CbB hotfix? What happens if you use Swatches instead? Link to comment Share on other sites More sharing options...
abacab Posted January 28, 2021 Share Posted January 28, 2021 (edited) 5 hours ago, Starship Krupa said: Interesting. You're running the latest CbB hotfix? Nope. Stated in my previous post that I was running 2020.11. Always stay one version behind the curve. No change with memory in use or commit charge with Swatches in Player or Chromaphone 3. The latest hotfix was released for 2021.01. Edited January 28, 2021 by abacab 1 Link to comment Share on other sites More sharing options...
Christopher Theodorou Posted January 28, 2021 Share Posted January 28, 2021 Hi, if you see my other thread, I'm experiencing a lot of instability with Chromaphone 3 and Dimension Pro. I don't suppose you have Dimension Pro in the project? I am currently in touch with Eric at AAS about the issue, but they need Dimension Pro to proceed! Link to comment Share on other sites More sharing options...
abacab Posted January 28, 2021 Share Posted January 28, 2021 (edited) 1 hour ago, Christopher Theodorou said: Hi, if you see my other thread, I'm experiencing a lot of instability with Chromaphone 3 and Dimension Pro. I don't suppose you have Dimension Pro in the project? I am currently in touch with Eric at AAS about the issue, but they need Dimension Pro to proceed! You were using CbB 2020.09 when this first occurred. The error experienced by DimPro, "Exception code: 0xc0000005" is a memory access violation, one of the most common errors on Windows. Dimension Pro is no longer sold or supported. It was replaced by Cakewalk under Gibson with Rapture Pro in 2015. Support for both definitely ended when Gibson shut Cakewalk down in 2017. There is no guarantee that plugins that have reached end-of-life will be supported on any current DAWs. That's probably the reason your attempts at getting support for it are reaching silence. I'm sorry to hear of the troubles, because I like DimPro too. Fortunately it hasn't crashed on me yet. Edited January 28, 2021 by abacab Link to comment Share on other sites More sharing options...
abacab Posted January 28, 2021 Share Posted January 28, 2021 (edited) If you're up for some deeper diving, and want to take a look at the threads, handles, DLLs, stacks, etc. involved with Cakewalk or any other executing program, check out Process Explorer by Microsoft Sysinternals. Maybe a clue to a misbehaving process lurking somewhere? https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer Quote Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded. The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded. The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work. Edited January 28, 2021 by abacab Link to comment Share on other sites More sharing options...
abacab Posted January 28, 2021 Share Posted January 28, 2021 Here is the thread view for just the main Cakewalk process on my PC. You will see a thread for each plugin. Each thread has a stack view that can be accessed by selecting the thread, then clicking the "stack" button. 1 Link to comment Share on other sites More sharing options...
abacab Posted January 28, 2021 Share Posted January 28, 2021 (edited) https://docs.microsoft.com/en-us/windows/win32/procthread/thread-stack-size Quote Each new thread or fiber receives its own stack space consisting of both reserved and initially committed memory. The reserved memory size represents the total stack allocation in virtual memory. As such, the reserved size is limited to the virtual address range. The initially committed pages do not utilize physical memory until they are referenced; however, they do remove pages from the system total commit limit, which is the size of the page file plus the size of the physical memory. The system commits additional pages from the reserved stack memory as they are needed, until either the stack reaches the reserved size minus one page (which is used as a guard page to prevent stack overflow) or the system is so low on memory that the operation fails. It is best to choose as small a stack size as possible and commit the stack that is needed for the thread or fiber to run reliably. Every page that is reserved for the stack cannot be used for any other purpose. A stack is freed when its thread exits. It is not freed if the thread is terminated by another thread. Edited January 28, 2021 by abacab 1 Link to comment Share on other sites More sharing options...
ChristopherM Posted February 3, 2021 Author Share Posted February 3, 2021 Well, I'm happy to report some positive progress here, at last. I can load the AAS instruments now, quickly and successfully with no sign of the memory-hogging. The key was resetting my entire AUD.INI to default (something I did after AAS's tech guy asked me if I had altered anything from default, as he could not replicate the behaviour). It occurred to me that, as I have used Cakewalk for many years, the init file has presumably evolved along the way. The first use after this was not encouraging. When I attempted to load Chromaphone 3 VST 3 by dragging and dropping within Cakewalk, the entire Cakewalk GUI vanished instantly. Cakewalk.exe continued to appear in Resource Monitor, but with zero CPU and occupying its normal amount of RAM (i.e. the previous RAM-gobbling behaviour was not present). After some time, Cakewalk.exe silently exited, the GUI never having reappeared. To cut a long story short, each time I restarted PC and/or Cakewalk then attempted to load the AAS instruments, I got a little further (although with two different Unhandled Exceptions along the way). I now seem to be able to load these instruments successfully. However, I'm very puzzled as to what the initial issue was and also why these following instabilities happened, but are seemingly not reproducible at will (even though I have made no further changes to AUD.INI). I'd be interested to hear @Noel Borthwick's thoughts on any of this. I have the original aud.ini and the mini-dumps from the UEs for anybody sufficiently curious to want to examine them. All observations gratefully received! Link to comment Share on other sites More sharing options...
abacab Posted February 3, 2021 Share Posted February 3, 2021 If it ain't reproducible, it ain't fixable. Unless you get really, really lucky and you fix it by chance when randomly tweaking stuff. When I worked in IT support, the first thing we learned in order to triage a problem report was to first determine if it was an isolated incident, or it was happening to others, as in a widespread issue. If it was happening to others, then there was usually something in common, and it was only a matter of time until somebody reproduced it. But the hardest problems are the unique ones that only occur to a single user. In that case, I would recommend to try it on another PC. Eliminate as much as possible, because it is likely that the problem lies somewhere on the individual PC in question. Support is not likely to find an answer if this is the case, unless it can be reproduced. Link to comment Share on other sites More sharing options...
Jonathan Sasor Posted February 3, 2021 Share Posted February 3, 2021 We've reached out to AAS for some test versions, and in some initial testing, I was able to get some instability when working with Chromaphone, but not consistently. From what I could tell it appeared to be an issue on the plug-in end rather than on CbB. Based on @ChristopherM's description of the app disappearing, that would also lean in that direction. We'll do some more digging as time allows and also pass our findings to AAS. If you're able to get any additional details or dump files related to the crash, please let us know and we'll take a look. Link to comment Share on other sites More sharing options...
ChristopherM Posted February 4, 2021 Author Share Posted February 4, 2021 (edited) @Jonathan Sasor - thank you for your engagement with this. I have PM'd (in three parts) the relevant files. Edit - I have also added a link to an (18GB) dmp obtained by procdump64.exe during the memory-hogging phase. Edited February 4, 2021 by ChristopherM Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now