|
|
Post by carbondoggo on Aug 4, 2021 1:37:15 GMT
Hi, im still unable to play CDE due to instant crash on startup, does anyone have a solution?
Heres my crash log:
Version: CDE 1.2.1.3 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
|
|
|
|
Post by cipherpunks on Aug 4, 2021 14:33:24 GMT
im still unable to play CDE due to instant crash on startup, does anyone have a solution? Replied via PM. |
|
|
|
Post by cipherpunks on Aug 10, 2021 11:24:35 GMT
Citing PM in public without explicit permission... What an awful absence of writer's taste.
The user is always the problem.
|
|
|
|
Post by carbondoggo on Aug 10, 2021 17:04:25 GMT
why did you send me a PM of the solution, instead of posting it for others who have a similar problem to see and use?
|
|
|
|
Post by cipherpunks on Aug 12, 2021 8:53:39 GMT
It was due to reason, and that should be obvious from content of my message.
I'm sorry if it is not, for you.
|
|
|
|
Post by carbondoggo on Aug 17, 2021 19:28:57 GMT
It seems like you were accusing me of hacking the game, am i correct in my assumption. if so how did you come to the conclusion?
|
|
|
|
Post by cipherpunks on Aug 17, 2021 20:47:22 GMT
???
You are not.
|
|
|
|
Post by carbondoggo on Aug 17, 2021 23:05:24 GMT
what was your message meant to help me with? it didnt seem to address the problem with CDE
|
|
|
|
Post by cipherpunks on Aug 18, 2021 12:15:00 GMT
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.
|
|
|
|
Post by carbondoggo on Aug 19, 2021 23:30:26 GMT
why would i call MS support for a CDE problem? from what i understand from your messages you are accusing me of using an unlicenced copy of windows or CDE. is this what you are doing?
|
|
|
|
Post by cipherpunks on Aug 22, 2021 1:57:40 GMT
why would i call MS support for a CDE problem? 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?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 yours PC as a result), and that - I think - you do not have in order enough to run some apps (like CDE.exe). Prove me wrong.Last time I checked, forum search function worked as intended. |
|
|
|
Post by carbondoggo on Aug 23, 2021 21:04:09 GMT
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.
|
|
|
|
Post by dragon on Aug 26, 2021 15:05:19 GMT
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.
|
|
|
|
Post by cipherpunks on Aug 27, 2021 3:10:27 GMT
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:...but you either sound like Microsoft employee, or your usage of the word "fact" is inappropriate here. aha, so that's a condition - no deliberate sabotage. Right. But then you say: 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. |
|
|
|
Post by dragon on Aug 27, 2021 17:00:37 GMT
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.
|
|
