Hi, im still unable to play CDE due to instant crash on startup, does anyone have a solution?
Heres my crash log:
Version: CDE 220.127.116.11 Windows
Assertion at \mac\home\documents\code\engine\system\steam.cpp(211): Steam API failed to restart. Success Error: EXCEPTION_BREAKPOINT 0 0x76f4f5c2 DebugBreak Line Info Error 487 1 0x00b6e344 ??0GameManager@@QAE@XZ Line Info Error 487 2 0x00b69d04 ?EngineMain@@YAXHQAPBD@Z Line Info Error 487 3 0x007abc43 _main Line Info Error 487 4 0x00bf3227 __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(283) 5 0x75e1fa29 BaseThreadInitThunk Line Info Error 487 6 0x77427a9e RtlGetAppContainerNamedObjectPath Line Info Error 487 7 0x77427a6e RtlGetAppContainerNamedObjectPath Line Info Error 487
Like I said, it was meant to be obvious from the contents of my message, and I'm sorry that it wasn't for you. Sad that you are seemingly not fit to do what I proposed to do; there's a fair chance it'd helped, though. What now? Call Microsoft support, naturally ;) Good luck.
Any other ideas? Keep in mind that currently you have no way to be sure that "your" OS is in order. Who would you call instead? Valve?
from what i understand from your messages you are accusing me of using an unlicenced copy of windows or CDE.
Your understanding is flawed. You can not quote my accusations, because I haven't posted any, yet. But if you want some, okay then, here: I think you're just an average consumer who was shoehorned into installing "Windows 10" (loosing control of formerly yoursPC as a result), and that - I think - you do not have in order enough to run some apps (like CDE.exe). Prove me wrong.
is this what you are doing?
Last time I checked, forum search function worked as intended.
all i wanted to do was play the game, i dont know what that has to do with my OS (i managed to fix the issue in the end by deleting all the CDE files in appdata, turning off wifi, starting CDE up, that time it worked, then i quit CDE, turned wifi back on and restarted CDE, allowing steam to overwrite the cloud files with the new ones, CDE now works fine)
on another note, how do i use the search on this forum, i cant ever seem to get results that match what i want to find. eg, i want to find the solution to reactor design regarding an error "Generates more heat than it can dissipate" when i type: "Generates more heat than it can dissipate" into the forum search bar there doesnt seem to be a related result.
You may want to search the site using Google, the forum search is crap.
As for the issue, I guess some files in the cloud got corrupted. It's not an issue with Windows 10, your OS is fine and this has nothing to do with it. In fact, Microsoft had managed to make messing up Windows 10 pretty hard as long as you don't deliberately start overriding things. It's Linux that'll scream and die if you poke the kernel the wrong way.
It's not an issue with Windows 10, your OS is fine and this has nothing to do with it.
Right, user tries to run Windows executables on Windows OS, but Windows OS has literally nothing to do with it. Right.
Then you say:
In fact, Microsoft had managed
...but you either sound like Microsoft employee, or your usage of the word "fact" is inappropriate here.
to make messing up Windows 10 pretty hard as long as you don't deliberately start overriding things.
aha, so that's a condition - no deliberate sabotage. Right. But then you say:
It's Linux that'll scream and die if you poke the kernel the wrong way.
Deliberately poking the kernel, huh? I call you a hypocrite and I call double standard on your post. Prove me wrong.
Linuxes of "the Golden Age" prior to "great reset" tribulation were striving to be more like BSD UNIXes, and so there was strict decoupling of user data from system files. IOW there was no "registry" to speak of. As long as your filesystem was fine, you could boot from USB and use your files and settings. This is not at all like in any version of Winblows, where "registry" is coupled into OS so if the OS dies, you have lost your settings.
Moreover, possibilities to recover from bad UNIX/Linux kernel settings are many and are more or less straightforward, when possibilities to recover blown winblows instance were always limited by design, and you're just a control-less renter (read EULA). That's pre-systemd pre-EFI era generalization, but it still remains so to this day in general.
It would be wise to do any IT troubleshooting starting with as clean and as controlled environment as possible, and that was my point all along.
The difference is, 99% of Windows users won't need to ever use overrides in question (as opposed to Linux, where poking the kernel at your leisure is a feature). Windows locks both the users and anything they use in a padded cell exactly so they can't break things. The only time I've seen a blown Windows 10 instance was after a mid-update power hit, and that was recovered from by... booting from a recovery USB into console and typing a few commands. I'm not sure if Linux would've fared better, and from my experience with it, it'd have involved the console either way.
Source: I use Windows 10 with several group policy, registry and setting tweaks enabled. Some of that was hard to access, but it's a small price to pay for preventing the average luser from messing with these. That power hit was the only time I needed to recover anything, and the only BSODs I ever got were due to overclocking too much. You actually have a lot of control over professional Windows 10, you just have to pretend you're a corporate sysadmin and not an individual user (and the group policy UI is still better than the console).
Bottom line is: on Windows, if a program crashes with a weird/no error message, it's almost certainly a badly written program (anything a user can cause should have a clear message, so user errors are in this category) or file corruption due to external causes, usually 3rd party AVs or flaky hardware. In Linux, it might also be OS configuration, OS/program/driver version mismatch (don't get me started on backwards compatibility in Linux), permission issues... Your attempt at "troubleshooting" is the best example of it - you assumed something that simply doesn't happen in modern Windows versions, and in process missed the actual, remarkably simple solution.