Infinite loop

[Anixx]

This is what happened to me two times already.

1. Crash of DWM. I think ExplorerPatcher is not the cause, but cannot be sure.

2. After the crash I am thrown into the logon screen. I re-login. DWM is not on (no acceleration of windows).

3. The taskbar appears briefly, but with no task buttons, black unskinned areas, no start menu and tray.

4. Then shortly after that the taskbar disappears and I see a message box that "An error had occured when servicing this software..."

5. The taskbar briefly re-appears again, and this continues in an infinite loop.

If I shut off the computer with the power button, the infinite loop continues after logon.

Last time I managed to get from the loop by clickling on the taskbar in a brief moment when it was visible and entering Explorer Patcher's preferences. There I unchecked the "Notify about updates" feature. After that the Explorer stopped restarting.

My guess is that one cause of the problem is that the Explorer Patcher tries to check for updates even when it just had re-started the Explorer due to failed check for updates. Possibly it should check for updates only once at logon.

The other cause of the problem is if the checking for updates failed, it restarts the Explorer anyway. Possibly, it should not.

[valinet]

Currently, it does not restart when the update check fails. Restarting is done by the updater anyway. Are you on a supported build? Please investigate thoughtfully, establish clearly what is happening, no one can work based off presumptions. Try with, without it as shell extension, debug it a bit. EP has nothing to do with DWM unless set as shell extension, in which case it may be loaded in there as well, idk... Also, DWM crashing should not throw you on the login screen, but only reload the image on the screen. winlogon crashing might throw you to the login screen. Anyway, try to reproduce everything on a clean install or to find a clear reproducible pattern.

Thanks

[valinet]

Just checked. consent.exe is only 192 KB. Definitely, the dialog is not there.

I like how you clearly invested the time to investigate it throughfully by disassembling it and taking its guts apart and you can clearly state that. No shade of doubt, indeed. 😂

Idk, you’re probably right, but being 192KB only is not an argument at all, 192KB can fit a LOT of stuff, especially a call to a function which takes as argument the type of consent dialog to create, for example, using internal or external code 😉

[Anixx]

There is also a file ConsentExperienceCommon.dll

[Anixx]

I actually did program in assembler and debug code when at school. On a Soviet analog of PDP-11. For, instance, fixed the game Joe Blade and some others so that it to load its files from a floppy using standard system call rather than from tape recorder.

I also wrote some addons the the OS graphical file manager that allowed to change the volume's (FAT12) label and some other properties via a graphical dialog displayed over the NC-like file manager. All in asm debugger (+using non-commands "WORD XXXXX" to call system interrupts).

I lost the interest in assembler though after transition to x86, because of the ugliness of its architecture.

[valinet]

Oh, wow, interesting. I mean, nowadays, tools like IDA come with decompilers, they don’t show you just the op codes and disassembly, they can also generate a C-like pseudocode based off it. Idk, try it, look on the system files, they are also augmented with symbols, and maybe you find some answers, they have to be there. That’s the only sure way to figure it out eventually, like, everything has to boil down, at some point, to a bunch of instructions executed on the CPU.

[Anixx]

Well, I tried to replace consent.exe (+mui) and it did not work, reporting 'filesystem error".

Replacing via debugger key just does not affect anything.