Thomas S Carlisle

Just a quick follow-up. After continued testing of this, I can only arrive at the conclusion that this is a valid issue. I also have since found this thread saying pretty much the same, nearly a year ago. Except, I think the issue has not only not been resolved but has worsened. Here is why I say that: 1) I can confirm the "media browser" window is NOT pointing to "Desktop", yet any time one creates a new project, or opens an existing project, the application opens any zip files on the Desktop. Thus the work around discussed in the below thread is no longer a work around. 2) It is not a "corrupted zip file". While it is true that winfldr.dll chokes on it, it is not a malformed zip file. But, it is a zip file that has a lot of objects and takes considerable time to uncompress. However, the cakewalk application never completes this operation, and it crashes but doesn't close the application window and any processes it launched. It is not a matter of waiting -- this will never complete and it does result in a hung application. 3) Even if it did not lead to an application hang, this behavior would certainly raise brows from a security and privacy perspective. One reasonably expects cakewalk to limit its access of user files to only the directories that are relevant to the users work. This behavior -- opening zip file son the users desktop -- occurs regardless of where the project folder is located, etc. 4) I would guess the reason the application is scanning and opening zip files, is to make it easier for non-tech savvy users to work with loops and other content they have in compressed form. If that is the case, and this functionality needs to continue, there really should be something in the pop-up (where its says "Creating UI") that informs the user what zip file it is attempting to open. Because this is a critical path operation which has the potential to run long, or in this case crash the app, it is just a good practice to clue the user in on what was being attempted. Cakewalk is, in my opinion, an extremely complex piece of software which amazingly runs very solidly. I know because I was a paying customer since Sonar 7. I believe that addressing this issue will result in an even better "out of the box" experience, and close off what many would consider to be a privacy concern.

I think I made it clear in my post, that where I think there is room to improve is in providing logging -- or some other form of feedback -- so that troubleshooting something like this takes minutes instead of hours. Also, I want to clarify, I did not invoke cakewalks browser functionality to open this file, and cakewalk IS trying to open it -- for whatever reason -- when trying to create a new project. That alone is cause for serious concern since: a) it raises privacy and security concerns b) it is coded as a critical path element which hangs the entire app And also want to clarify, this zip file was NOT in the folder that my project was in -- or was to be in . I am sure I made that clear. But since I am now able to create a project, I can confirm opening an existing project does not cause cakewalk to access zip files on the desktop. Bottom line, is this app is deciding on its own, when creating a new project, to crawl files on my desktop and if it is a zipfile to unzip it. It is worth noting, the zip file is not malformed. For whatever reason windows chokes on it. I can't speak to why because it isn't my code. If cakewalk depends upon zipfldr, then cakewalk needs to handle accordingly.... with feedback to the user and an option to terminate whatever task is trying to unzip the file. I just can't think of any good reason that creating a new project should need to open zip files on my desktop, so even if it doesn't stumble on a zipfldr issue, it still is something that should be looked at.

There are several threads over the past few years of people having this issue. I experienced it, troubleshot it, and resolved it. The TL;DR version is: 1) If the app provided logging it could have been solved in minutes. 2) Why was the app even trying to unzip a zipfile that is not in the content directory or the project folder?

First, let me say I have been a faithful Cakewalk user since about 2010, so I am not new to the product. I am an IT Professional with about 30 years experience, so not new to the concepts of software installation and troubleshooting. Also have been a developer so not new to the concept of applications should not swallow exceptions -- and I do think that is what is happening here. Lastly, applications should provide feedback to the user, ideally a log file that users can use to troubleshoot and understand what conditions made the application go into a bad state. So I post this to help others who land here, and also hoping that the dev team considers making this product more supportable, e.g. through logging. Because that would have saved me literally about 10 hours. Just to mention: in troubleshooting this I found this: And a few others. At the end of the day, it wasn't board drivers, chipset INF's, video drivers, etc. It was due to having files on the desktop. Not files having to do with a cakewalk project, e.g. not loading a project from a folder on the desktop. Not, it was because I had a file related to software development on my desktop. It was a zip file of material icons, and for whatever reason cakewalk was trying to do something with that file -- over and over and over and was stuck. Once I was able to see something that pointed me to this, it was an easy fix --- stop leaving junk on the desktop. But how much I had to do to be able to see what was happening, was entirely too much. This is where an application logfile would really have helped, because I'd have seen in that app log the attempt to open that zip file over and over. Lacking that, here is what I did: 1) Went to another computer and installed. I figured if it did the same thing, no sense looking further. But, if that were the cae there would be a lot of posts about the problem. So I did expect it to work, and it did. Problem is, I want it to work on my most powerful rig. 2) I created a dump file of the task, and opening that with windbg gives me this: 00000000`001471d0 00007ff8`f812e5ac : 00000000`00147726 00000000`00147310 00000000`2160d170 00000000`00147310 : zipfldr!CEnumArchive::_DirExistsInEnumerator+0x48 SYMBOL_NAME: zipfldr!CEnumArchive::_DirExistsInEnumerator+48 MODULE_NAME: zipfldr IMAGE_NAME: zipfldr.dll FAILURE_BUCKET_ID: BREAKPOINT_80000003_zipfldr.dll!CEnumArchive::_DirExistsInEnumerator OS_VERSION: 10.0.19041.1 BUILDLAB_STR: vb_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 IMAGE_VERSION: 10.0.19041.789 3) From this, it looks like an exception is thrown in the zip module within one of the C++/.Net assemblies. So off I went to ensure the c++ redist is right, etc. to No avail. If only I had a way of knowing what file the app was trying to zip or unzip.... again, an app log that shows things which are attempted but not successful would be a good thing. 4) Next I tried to run cakewalk from another account on the computer. It worked! Ok, so just use another account for music production. Not a big deal. But the tech inside of me just couldn't leave it at that. 5) Clearly, something about the user profile was the issue. So I went through the process of trying to rebuild the user profile and just make the account this app works under be the account I use for everything. But, once I got all the appdata and files migrated to the working user profile, now the app doesn't work under THAT profile. Interestingly, it now worked under the original profile. 6) So clearly, it isn't the account or the registry of the account, but something in the files. So I migrated files back to the original account, and sure enough the original account no longer works and the other account works again. I wish I had a way of knowing what files the app was trying to open or create.... again, logging is your friend in 2021. 7) I spent some time trying to narrow down which files make the issue appear/disappear, but it is like a needle in a haystack. Finally, I used procmon64. Since I knew the problem was file driven, not registry driven, I could filter out and just show files. Still, it was a lot of stuff to wade through. But I was able to find, after the point that "Creating UI" appears and the app hangs, I was able to find a lot of attempts to access that zip file on my desktop. So I copied all files on my desktop somewhere else, and now cakewalk works. And last, but not least, if I copy that file back to the desktop, it breaks cakewalk. What file was it? Material Design Icons: https://github.com/google/material-design-icons/releases/tag/4.0.0 It turns out, for whatever reason, if you click on that zip file in windows, windows explorer hangs trying to open it. 7zip opens it just fine. Thus, the underlying issue is this zip file somehow being incompatible with windows native libraries that apps use. If this was a zip file in my project directory, or in my content directory, or my VST folder(s) I would understand it, and would have honed in on that pretty much immediately. But without any logging information to go on, I would not think to consider zip files that are outside of those specific areas which this app should be using. And no, I wasn't storing the project on the desktop. Yes, I get that apps like this will "watch" the files/directories under the project folder so the app knows of external changes. There is no reason cakewalk should have been "watching" my desktop. So I guess in conclusion, I began thinking I was recommending the app implement logging, so users understand what might be going on when the app doesn't work as expected. But now, I am recommending the app developers look at this because whether it is intended or not, upon close examination the app does appear to be looking outside the bounds of the project folder, and raises brows from a security/privacy perspective.