My issues with Capture One v20 - Capture One does not support Windows 10 1909
The issue started when ever I tried to save a workspace, either a old one or create a new one. The system crashes. I mean it just dies and the crash reporter starts. This did not happen in v12 or the Beta versions of v20. So I sent in a support request. After having a few more crashes I finally got a response from support with the suggestion to:
- Re-install Capture One - uninstall it and reinstall a "fresh copy". I did - three times using software that scans the registry for left over bits and pieces (which Capture One has a few). Interesting tidbits: It took three times/re-installs to get up and running. I had backed up my styles/presets/workspaces and the default install just plain ignored "some" of them.
- I did not hear from Capture One for quite some time, during which I have the system sort of set up to work like I want it.
- I had the system crash on me while editing metadata presets that I have had over the years on my 17K image "master" file. This is not new - it has happened since v5.
- I got a message last week from Capture One suggesting that I - here is the good part.
- Re-install Capture One - again.
- Roll back to Windows version 1903 as "its official" that they do not support Windows v1909.
I am becoming really disappointed in CO's ability to support Microsoft. It takes well over 30 minutes to initialize my "master" catalogue on startup. Elements of the metadata that have been purged from the catalog literally years ago - still show up - meaning that I have had copyright/phonenumbers/addresses that were misspelled in v10 or so that still show up when I filter on those fields.
Now don't get me wrong - I love CO over the other software packages that I have, but I am convinced that they will be dropping Microsoft in the near future. Especially when Apple goes to their own CPU.
Rant over.
-
SFA
This is not a Microsoft issue - it is a Capture One issue. OS upgrades are not the problem.IanS
This is not a GPU issue. Capture One is failing during a write to disk function, the GPU has no effect when writing a file to the disk.BeO
I have discovered that most non-Microsoft and Microsoft programs leave unneeded entries in the registry. Using the third party program to un-install programs actually clears out left over registry entries where using the Microsoft uninstall function just leaves this crap in there.Heinz Weber
Yes, I have verified that the file system is healthy/defragged and that the folder permissions have not changed since Capture One was installed on this system.Now, as to my experience with PC's/Windows. I spent 30 years supporting Windows in global corporations starting with MS-DOS systems up to Windows 8.0 (when I retired). I have created corporate images for Windows that were distributed to well over 100,000 devices. I buy components and build my own systems. I was on the Windows 95, Windows 3.0 and Windows NT Beta teams. I supported Windows Server (various versions) physically located across the US, India, Isreal and Russia in software engineering environments.
So, let me reiterate - My issue is not based on Microsoft Windows - the issue is with Capture One. My question to you is can you save or create a new workspace on your machine? And just for giggles here is the text from Capture One.
"Sorry for such a delay, we are experiencing a large volume of cases due to the last release.
Please note that as per our release notes your Windows 10 version 1909 is not supported and you're running the app in unsupported environment - bugs are expected.
Capture One 20.0.2 supports Windows 10 Anniversary Update (build 1607) through to build 1903.I'd recommend trying to reinstall Capture One with our instruction just to make sure it's a clean install: How to uninstall Capture One?
If you still face the same issue, please consider downgrading your OS."
Emphasis is mine. Good Grief.
1 -
There are no such log entries on my system. The logs go back to July 2019. The exit code -1 is the one shown in my listing above. Your error does not show up on the crash listing for because the error is not a truncated xml file. There are 21 messages in the application event log with capture one crashing with exit code -1. There is no, nada, nothing, butcus in the error message to suggest that xml is the issue. The only difference in all of these messages is the date/time stamp with some of the paths showing the path to 20.0.0 Beta folder. I did not run into this issue with any of the Beta's, it was with the production version of 20.0.2 that most of the crashes occurred. Let me say again - when the Save Workspaces menu item was clicked/selected the capture one screen went blank and the crash reporter was started. The only Event Viewer message is the exit code -1, meaning that the process referenced died/halted/quit. After the system crashed consistently several times I opened a support ticket and provided Capture One logs and current system profile beginning on 2020/02/08.
The only real suggestion from Capture One is listed in the above quote I posted. I.E. uninstall/reinstall or downgrade your OS.
Again - it is not my responsibility, nor is it yours, as a user to debug the code for Phase One. It is pretty obvious that you did not replicate the issue I am having.
Upon reflection, of posts here I did another bare metal uninstall/resinstall as outlined in my last message with particular attention to copying Workspaces from older versions of Capture One. Once the "bad" xml file was discovered, I deleted it and verified that I was able to save new and existing modified Workspace files.
I am taken aback that Capture One has no clue about such an issue or how to handle such an issue. Their response of "It's the OS version" just does not hold water.
As I said in my last message, I will contact Capture One, report my findings and close the support ticket. Hopefully, they have entered a snipit of information into their bug watch list. To have a application undergo a hard crash because of a corrupted xml file is very surprising and it should be looked into by Capture One - no you or I.
1 -
Again, my system is up to date on MS patches. This patch was from April of 2019. My system was updated to feature release 1909 in July 2019 this kbpatch was already on my system.
This is/was not a OS path level issue. It is the very strange application behavior that has been brushed off by Capture One as a "unsupported OS version" issue. As I stated multiple times above, it is not the responsibility of users to debug the application.
As for this thread - the most important response, to me, was from @IanS where he stated that he was able to save/modify and save Workspaces. This pointed me back to the set of Workspaces on my device. I did take Capture One's support recommendation of uninstalling/reinstalling the application in order to work through the issue.
The two things that I see that are important - Capture One can be very fragile when working with corrupted xml files. It is interesting that once a malformed xml file is in the Workspaces13 folder - any attempt to save a Workspace will cause the system to have a hard crash where the only Windows Event is a exit code -1. (EventID 3000, Process Exit Monitor). The second is Capture One's statements about the OS version. Many of us are using 1909 with Capture One 20.0.3 (updated yesterday) v13.0.3.19 (d9cb669) and Capture One gives the impression that if you are using 1909, they will blame the OS rather than attempt to provide some other guidance.
Anyway, this ticket is going to be closed in the next few minutes. My particular issue with Workspaces has been solved to my satisfaction.
1 -
I am using C1 20 with Win 10 V1909 without issues, so it might be something else on your system? Have you updated the GPU driver?
0 -
I am using C1 20 with Win 10 V1909 without issues too. (Maybe I should not tell this here if I want to have support from the company?)
I have a fresh Windows image install of 1909 made in January (because of a C drive failure).
I read that you use 3rd party software to clean Windows, this was probably a good idea with earlier Windows versions but I tend to believe that this era is somehow over with Windows 10. Not that Windows 10 is perfect but maybe Windows "addons" are less useful now and sometimes the side effects of such software may become more often noticable.
0 -
I'm also surprised about the Windows version - I'm using Win 10 / 1909 since some time - without issues. First with CP1 12, now since it's out with CP1 20. No crashes so far ...
Did you check file system / hard disk / anything around?
0 -
Have you also asked Microsoft about why they like to cause people so many problems with their "updates"?
That's a question more appropriate for Mac users.
0 -
From what I have seen reported MS are catching up with Mac policies in some things that are OS related.
0 -
Apologies for not being clear in my first post.I can create new workspaces and modify existing workspaces without any issues. This is why I said I am using C1 20 and Win10 1909 without any issues.
0 -
Thank you for the clarification. I will now have to pursue other options.
I am still "bothered" that the issue is occurring without fail. Now, it seems that in order to log on to the support site I have to request a password reset - each time I log on.
Support has really gone downhill.
0 -
Hi Pdlanum.
There is something I do not understand. You wrote "I had backed up my styles/presets/workspaces and the default install just plain ignored "some" of them." , and that you deinstalled C1 completely and even used cleaning software for the registry. Why do you expect C1 would appreciate your backuped customization after a fresh install? Did you deploy your backuped settings before the crash happens? If so, maybe it is worth trying a fresh installation, and your plain catalog, without deploying your backuped settings to see if the crashes can be reproduced.
Second, as you have IT knowledge, do the C1 log files or eventviewer give you some idea about the crashes?
0 -
I sent basically the following to Capture One support.
copied the capture one folder out of my account and the capture one folder out of the "program files" hidden folder to an external hard drive. This copied all of my personal and installation information to a separate external hard drive. I disconnected the external hard drive.
I logged on to the Phase One site and deactivated the license. I un-installed Capture One from the PC using the system that scans the registry. I deleted the Capture One folders - and what ever was left over - from the hard drives. Please Note: I know how to delete information off of a hard drive - i.e. no recycle bin.
I did a install of v20.0.2 on the system - a default no extra styles, presets, recipes or list of catalogs. Brand new activated install. created a new blank catalog i.e. no images, no history, no added on presets, styles, recipes or personalized workspaces.
I explicitly loaded the default workspace - modified it and attempted to save it. The system crashed immediately. I gathered all that information, including the crash files and OS information files and sent them off to Capture One support under my existing case. The highlighted response above was Capture One's response after a week or so.
I have copied my styles, presets and recipes back into the Capture One folders. They all work as desired - except for workspaces.
My analysis of CO logs is not something where I have the understanding or debugging tools. eventviewer is not a tool used for post crash debugging. Windows logs basically say --- Dude these processes died at date-time. Since CO is not a Microsoft program the use of MS logs is not all that helpful.
I did not do a blanket restore of the previous folders onto the new install.
0 -
Pdlanum wrote:
"This is not a Microsoft issue - it is a Capture One issue. OS upgrades are not the problem."
Are you sure? Their recent record has included recommendation NOT to install Win 10 updates they had only just released.
Millions of users out there may disagree with your assessment.
0 -
@Pdlanum
FWIW,
I don't have to request a password reset every time I sign to the support site - old or new. Have you some security setting that being a little over-protective for this particular purpose?
I don't recall anyone else mentioning that either. You do need a new password at first connection because it's a new system. No shared password between old and new forum. That is probably wise for security purposes (and bot driven anti-spam measures) but of course some may elect for their own convenience to use the same password.
0 -
@Pdlanum
Again FWIW ...
I have never (Using Win 7) had any evident problems of any significance installing C1 updates or upgrades using Win 7.
I regularly install new Version alongside previous versions. Sometime updates in parallel too.
I tend not to mess with the Windows registry unless I really need to although I am not averse to editing entries if required.
If you are having problems saving workspaces (but it does not seem to be a folder access issue) then one possibility would be that you changes to tools in V20 may have left you with a tool setting that is now obsolete - either as a tool or something to do with scrolling and fixed section of of the tool tab facility. This might be more of a problem if you are trying to save over a pre-existing but possibly corrupt Workspace definition.
However, from what I read of your description of your problem it sounded more like an obscure access/permissions sort of result and the Windows crash report might offer a clue if you have one a copy of it (or can create one.).
When you saved the Default workspace did you do so giving it your own name? You should, if only because at the next update your modified "default" will be replaced by a new one.
All user generated personalisations (or nearly all of them) are to be found per user in the user>appdata>local folder entries.
There are still, AFAIK a couple of run time only exceptions that only exist in the userconfig file - for logical reasons at this time.)
Bear in mind that the Workspace will also want to know about which Keyboard Shortcuts setting you are using. Once again I have never had a problem with such entire being carried forward from one install to the next. In the rare situations when changes have been significant and required user actions the needs were well documented and prompted at the point of first use.
I am absolutely certain that the issues you have would be annoying but equally sure they are rare - possibly extremely rare. Maybe unique. In which case the Support Team may not have any previous information on which to draw to offer you a solution.
Which Anti-virus tools are you running?
0 -
We don't really know if this one incident is a Windows issue, computer issue or a C1 issue. The problem is that C1 is so far behind on keeping up with Windows updates and that they are just dismissing problems people hare having with "roll back to a supported Windows version". I get there is a lag but Win 10 1909 came out over three months ago which means developers had access to preview versions even before that.
It is great - and expected frankly - that most people are working fine on Win 10 1909 the issue is if any one of them did run into a problem with C1 they would get told "roll back to a supported version of Windows". That's the part that is annoying here. How is that support? How is being four or more months behind on OS support considered support? I get that there will be some kind of a lag but Phase one has released new versions of Capture One since 1909 was released. Sorry I don't think that is very good support.
And yes, I have created a support ticket about this. And given them a "I'm unsatisfied" when I got the usual stock answer about not discussion futures.
0 -
@BeO
Please re-read my comments. I did look at the crash dump file and the Windows log files (i.e. EventVwr.exe - something I look at periodically).
The following is a entry from the Windows Log: "The process 'D:\Program Files\Phase One\CaptureOne\CaptureOne.exe' was terminated by the process 'D:\Program Files\Phase One\CaptureOne\P1.CrashReporter.exe' with termination code -1. The creation time for the exiting process was 0x01d5ea9f9a2fc0aa."
Not all that helpful huh - i.e. "Dude Capture One stopped and CrashReporter started"
As I am not a Capture One developer, why would you think that I would have been able to find a easy solution to what is going on? Capture One has their logs and information (MSInfo32 dump) on all installed and running programs on my system - per their request. Are we supposed to be analyzing "fixes" for issues now?
@SFA
Once again, I did not restore or copy my presets, recipes, styles before testing to see if the system was going to fail again. I copied the Capture One folders out of the "Program Data" folders and the appropriate Capture One folders for my two accounts located in "AppData\Local\Capture One", notice that I said COPY and I disconnected the external drive.
I deactivated the license, uninstalled the program using software that cleaned the registry and I then physically searched for folders named Capture using the paths mentioned above and deleted any existing files.
I reloaded Capture One and did a on-line activation. I created a NEW catalog naming it "blank" (i.e. no images) and went to workspaces selected the Capture One workspace "Default". I then modified the Default workspace adding the grid tool to the exposure tab. I selected workspaces (on the menu) and selected "Save Workspace" - the screen goes blank and the CrashReporter starts. No prompt for a name - the source "default" workspace is the one from Capture One.
0 -
Well, knock me down and call me Nancy.
I have discovered the issue.
It was a corrupted xml (ironically from Phase One) file in the workspaces folder.
- I took Capture One down to the bare metal again. Deleting the program and all the accompanying files from the two accounts I use.
- I reloaded Capture One and discovered that I could save custom workspaces.
- I then went to my backup copy of the Capture One settings for that profile and copied over the previously saved workspace versions one at a time testing to see if the Save Workspaces menu item would cause a failure.
- I deleted those workspaces that caused Capture One to fail. (Yeah - more than one)
- Once I had a clean system, I logged on using my normal – non-administrator group account.
- The C:\Users\<UserID>\AppData\Local\CaptureOne\ImageCore\13.0.2.13\ICOCL_all.xml set of folders and file were NOT created in the folder structure. When clicking on the activity spinner – Capture One Failed – as expected as it has happened before and is part of my support case.
- I created the appropriate folder structure and copied ICOCL_all.xml into it. Capture One worked just fine. (My graphics card is old enough to not be supported it – even though my driver version is 391.35 and Phase One suggests using anything greater than 306.97 would be fine.
- Suggestion: update the web page to reflect reality. (HA - I digress)
- I then loaded all of my personal presets, recipes and the selection of free styles that I have gathered over the years (yeah – years) and everything is working OK now.
I am about to install v20.0.3 – if all goes well, this thread should be dead.
0 -
Yes it is surprising and usually software can avoid this by catching exceptions, but hey, who knows which influence the oprating system has, see for example the Microsoft bug that caused applications to halt in some circumstances when using the Microsoft XML package, which maybe C1 is using too:
https://support.microsoft.com/en-hk/help/4493475/windows-10-update-kb4493475
"Addresses an issue that may cause applications that use MSXML6 to stop responding if an exception was thrown during node operations. "
0 -
The XML file crash may be tricky to catch.
A long time back - V6 or V7 as I recall - I had a session with about 2 or 3 thousand images that started to crash when working through the shots in file name order (mostly) about every 10 or 12 images. It seemed very random.
Eventually, about half way through my attempts to complete the set I was browsing the shots near the end of the set and spotted a slightly corrupt thumbnail. That seemed a little odd so I tried to regenerate it and it stayed corrupt.
I have a look at the .cos settings file for the image in an editor and it seemed OK but clearly there was something wrong. After several days of dealing with the crash problem every few images I wondered if this might be a clue to the problem. So I deleted the .cos file and re-edited the image giving a nice clean thumbnail and after that all was well.
I think the problem was that at some point the the file problems have been badly indexed (yes I got right into the file system at one point) in a "write" activity (Windows Competency) and one (or more fragments had been indexed in a way that could somehow be common with the fragments for other files in the set.
Thus re-assembling the fragments of an unrelated .cos file for another image picked up this errant fragment which then presented unexpected data to the process. Being entirely unexpected it was not trapped in the code and the process just failed. The same thing or something similar might happen if someone just hacked an xml file and added alpha character values where numeric were expected.
That was the only time I have experienced anything like that with the end result being straight crashing.
Other corruptions, sometimes reported and discussed in the forum, have usually resulted in an obvious visible corruption type of problem rather than a crash. I vaguely recall one or two around personalisations of one sort or another where the easiest solution was to re-create the personalisation rather than try to fix it. I don't remember anything right now that related back to crashing but it is not impossible that there have been some previous cases. Just not main stream regular support events.
This comment has been added simply to provide another perspective.
Grant
0 -
Sorry you are so obsessed with my issue. So, here I go again.
Yes - I followed Capture One Support's advice and uninstalled/reinstalled v20.0.2 three times.
The first time I copied the Workspace entries from the install that broke. The "backups" were copies of my folders for the installing account. The system crashed - as expected given what I know now.
The second time I uninstalled/reinstalled and copied only the Workspaces and a few other things like recipes, styles and preset that were from previous Capture One versions and those presets I created in the past. The system crashed. After this series of crashes I started this thread.
After starting this thread is when Capture One support contacted me and blamed the OS version. A knee-jerk response to say the least. During the conversations here I asked if users could save new/edited Workspace. Ian said he could and was running 20.0.2 on Windows 1909. Hence ---- a clue.
At that point I did a copy of all of my Capture One "yada-yada\appdata\local\Capture One" folders for ALL of my accounts. I also copied the relevant styles/preset/workspaces/recipe folders from the Capture One directory in "Program Files". I uninstalled/reinstalled Capture One for the first time - not loading any of my previous Workspaces/Styles/presets/recipes. At this point I uninstalled/reinstalled Capture One. I started copying MY Workspaces into the accounts Workspace folder. I tried to edit/save those Workspace files and they worked - right up to the point that I found a Workspace that caused a crash. I then tested to see if the successful saved Workspaces would load and allow edits ----- NO THEY LOADED, BUT ATTEMPTING TO SAVE ANY WORKSPACE CAUSED A CRASH. --- Problem, for me solved.
Your statements that you modified a xml file, i.e. corrupted it, and generated an xml open error is not a replication of the issue I have been having. Please Note: The system WAS ABLE TO OPEN THE "BAD" WORKSPACE AND ANY WORKSPACE IN THE WORKSPACE13 FOLDER. The system/Windows did not generate a error in the application log because there was no xml parsing issue. The xml parsing issue that you created by truncating/corrupting was not the issue. It was only when the opened/loaded Workspace was "saved" that the crash occurred. In fact all I had to do is click on "Save Workspace" in order to cause a crash - generating the "exit code -1" entry in the Windows application log. The screwy thing is that with a "bad" Workspace located in the Workspaces13 folder any attempt to save any Workspace would crash the system.
My "role" as a user should not extend to having to do detailed debugging activities to solve an issue - even if that issue is a one-off. And Capture One's knee-jerk reaction to the issue is really lame. My past experiences with support have been much better than this.
The OS is not an issue, the hardware (disk, disk controller(s), GPU, memory) is not an issue. The OS has been validated (read up on sfu and Dism). The system is running at the latest patch levels and I run Updates at least once a day - usually at startup.
I hope your obsession with this issue is resolved - let it go - you will feel better in the long run.
0 -
Comment on Windows 10:
I would be a newbie to Capture One. Been thinking about activating a trial for a client of mine, and came upon this thread. I have no idea if C1 will work well with W10-1909, but the advice given from C1 to stick with 1903 is noted.
That said, I have upgraded several dozen W10 PCs to V1909 with very few issues. But on one of MY OWN office PCs - go figure - the upgrade to 1909 was a total disaster. Regular BSODs, reboots, and hard crashes. And despite my troubleshooting, including restoring from an older backup image and doing the 1909 upgrade again (i'm usually real good at this), I finally gave up and did a fresh install, where it's been quite stable. I was starting to think it was a hardware issue, but nope.
So... I'm more pleased with W10 than I originally expected to be, but it's still a tiger by the tail some days. All that said, it's running very reliably on many computers that I'm paid to look after, and a few of my own as well.
I'm curious now to know if this issue has been fully resolved. A "save" issue could be related to antivirus - including WIndows built-in "Defender." And also if there are other issues related to W10 V1909.
0 -
I am running C1 version 20.0.2 on 1909 since a couple of months now and have no issue so far which I would attribute to the operating system. But this does not mean very much as I surely haven't touched every function in C1.
0 -
@PeterJay
The "Save Workspace" issue was resolved by removing all of the apparently corrupt workspaces. End of issue.
My system is running all patches for Windows 10 Pro v1909 x64 and Capture One v20.0.4 build 13.0.4.8 (cc4e1b5) is performing as expected. I have never had an issue running Capture One v20.x on Windows v1909.
My issue with Capture One was the apparent knee jerk reaction "all you have to do is" by support. Since I had been sending them failure/crash reports which stipulate in the first few lines what OS version is installed, I was pretty unhappy that after waiting for nearly a month for a reaction that this was their first response. As a retired Windows environment administrator when ever I hear someone say "all you have to do is" that sends off a gut level reaction that the person saying that has no clue as to what is going on. As for Windows v1909 not working on some systems, well, that happens. I have Windows 10 Pro v1909 running on 5 systems here (at home) on hardware ranging in age from 2008 - 2018 with only a few glitches. The only BSOD's I get is on the 2008 device which has network card issues that have been going on since 2010. The drivers have not been updated for years and they are somewhat fragile.
Has the issue been fully resolved? It might still occur if the Workspace files/system contains corrupted elements. I have removed the Workspace files that caused the issue and verified that all the workspaces in my environment are working without causing a crash. Both the OS and Capture One v20 have been very stable.
0 -
Ah, I misunderstood your motivation for your post. Seems you are not even willing to look into the application.log or application part of the eventvwr, although you claim superior IT knowlegde.
You are not seeking for advice and hints from other users but wanted to rant only. Rereading your post made this now clear to me, my fault.
Regards
-1 -
Pdlanum.
This is a user to user forum, if you post here I think it is fair to assume you seek help. I gave you advice / ideas to help yourself.
You are not obliged to follow all advice here but yes, if my advice is to look into the application log then I suppose you could potentially be willing to do so because you want the issue solved and seeked for advice. Then I realized you were not asking for advice but your post ended with "Rant over".
I still believe the application log can sometimes be of GREAT help to ordinary users who have a minimun of IT knowledge. For example, if I destroy one of my workspaces (cut it off after a few lines) then it will not show up in the workspaces menu, and here is the application log entry:
[2020-03-04 12:13:34.365][258][ID:001, Main]{APPL } | ERROR: Workspace 'C:\Users\...\AppData\Local\CaptureOne\Workspaces130\test.xml' could not be loaded. Exception: 'There is an error in XML document (21, 18).'
This test might be different then your corrupted xml but it shows my advice could maybe helped you much earlier. To prove or disprove this you would need to look up your own application.log.
regards
-1 -
Hi Pdlanum.
Here is what I do not understand. In your support case you stated that a even with a fresh install, saving a workspace caused a crash. None of your backuped workspaces was involved.
2 days ago you stated that you stripped down the C1 install to the bare metal, then saving workspaces worked, the you put each workspace one by one until you discovered a corrupted Phase One workspace from your backup (even several of them) causing this crash. I do not really understand from which backup you took these workspaces, your old customization backup or a backuped workspace from the stripping to bare metal trial, but in any case workspaces from the fresh install, as stated in the support case, caused the crash, probably due to a corrupted workspace in the downloaded install package, or corrupted during download, or corrupted during install, or corrupted during using C1, or any other process or hardware event. Or, the crash occurred from another, workspace file independant reason.
Something differentiates your C1 and or system from mine and many others, i.e. saving workspaces is no problem at all after having installed C1 20.0.2 on our systems. Which means "our" download package and install process yielded in a non-corrupted installation, or the computer system is reacting with a higher fault tolerance.
Now, that you can work without the crash, do you have all default workspaces installed, e.g. from the new install package, or not? (No need to answer, just because I do not understand what you did.)
As for the "malformend" xmls: I cut off a worspace xml in the middle of a line, that results surely in a malformend xml, and I do not have a crash, and even this malformed xml is detected and catched by C1 as proofed by my application.log file.
All of this leads me to believe that either your download or installation or system or even hardware (disk or controller) has an issue. I had a random freeze of my Windows system once in a while beginnging of the year and no diagnosis tool here or in the repair department of the vendor found anything, nor did a new Windows setup eliminate these random freezes, the only thing that helped was a new drive (m2 nmve in this case).
As far as the critique regarding support and our role as users goes: If a software is tested and supported for a certain operating system version and an issue is only occuring on one users' system who does not run the software on the tested/supported OS version, it is common practice to ask the concerned system to comply with the software specs and see if the issue persists. And remember, the company is granting you the right to install and use C1 (license), they do not distribute Windows images with C1 installed nor are they working in the same company as you, so yes your co-responsibilty and own interest is to "debug" (read: try to eliminate the issue). Reading crash dumps as you did is probably too much, reading application logs maybe not, but it is not "debugging" in the usual sense (walking live through the code).
But I join the critique that C1 is still not officially supporting 1909!!
I am glad you figured out / debugged how to run C1 and I hope I am wrong with my assumption that you have an undiscovered issue with your system.
-1 -
You are probably right, your role as a user should only be to pay a couple of hundred bucks and get first class debugging onsite worry free support even though you are not actually fullfilling the system requirements. How can I even think differently...
No worries, my obsession with this non-issue to has come to an end here.
-1 -
Have you also asked Microsoft about why they like to cause people so many problems with their "updates"?
-3
Post is closed for comments.
Comments
29 comments