FAR Manager crashes on application start

ujos commented 1 year ago

Far Manager version

3.0.6060.0

OS version

10.0.19045.2604

Other software

No response

Steps to reproduce

Add FAR Manager home directory to PATH environment variable
Press Win+R
Type far.exe

Expected behavior

App starts normally

Actual behavior

After some time I cannot run the FAR Manager using the Win+R shortcut. Now when I start the application, it appears on the display for a few seconds and closes. What is weird is it starts in small window:

Screenshot

That also happens when I run the far from the Windows Explorer from the C:\Program Files\FAR Manager\ folder.

In case if I create a shortcut and put it on the Desktop, then app starts well.
In case if I run FAR form the Command Line, it starts well.

I guess Windows OS had stored some weird FAR window sizes and applies now those settings on the app start.

Attached is an archive with the crash dump file: far_bug_report.zip

alabuzhev commented 1 year ago

Windows OS had stored some weird FAR window sizes and applies now those settings on the app start

Likely. Try removing/renaming HKCU\Console will all the subkeys, it will reset the settings. If you export that key and share it here, I can try to fix the crash as well.

ujos commented 1 year ago

Please find the registry hive attached. far_console_settings.zip

This behaviour is caused by FontName parameter. After I've removed that parameter application works well.

ujos commented 1 year ago

Probably that happened after I've updated the VS 2022 to v17.5

alabuzhev commented 1 year ago

I cannot reproduce it, the font just changes normally.

Does this font actually work in any other app on your machine? Overall it looks like something was wrong with its installation and the console host returns zero width and zero height to Far. If so, we can't do much but crash.

If you have time and inspiration, try putting a breakpoint here and check what the reported window and buffer sizes are.

ujos commented 1 year ago

I cannot reproduce it, the font just changes normally.

After I rebooted the computer I cannot reproduce this problem either :-\

While working on workaround, I deleted the FaceName key. If I restore the Registry values from the ZIP file above, FAR does not crash. I do not know what else is changed...

Does this font actually work in any other app on your machine?

I cannot confirm that. I have no other computer but this one. I've found that in the Windows Registry the FaceName key equals to "Cascadia Mono SemiBold". After I've upgraded the VS2022, there is no such font anymore.

Overall it looks like something was wrong with its installation and the console host returns zero width and zero height to Far. If so, we can't do much but crash.

I attached the DMP file to the ticket. Unfortunately there is no FAR.pdb file in the application folder, so I cannot load the DMP file and check what is happened. But I see you have a callstack in the bug_report.txt. On the top of the stack there is a std::memcpy function. Maybe if you still have the FAR.pdb file you can open it and examine the passed arguments.

If you have time and inspiration, try putting a breakpoint here and check what the reported window and buffer sizes are.

Unfortunately I cannot reproduce the issue. But I believe it would be great to solve it so it does not occur again.

Following is an extract fromthe bug_report.txt in the ZIP file.

003FD5B6   Far.exe!memcpy+0x126 (libvcruntime:memcpy.obj)
002B42BB   Far.exe!DoWeReallyHaveToScroll(short)+0x11B (interf.obj)
001733D9   Far.exe!ControlObject::ShowVersion(bool)+0x109 (ctrlobj.obj)
00172055   Far.exe!ControlObject::ControlObject(void) __ptr64+0xE5 (ctrlobj.obj)
002E808A   Far.exe!mainImpl(class span<wchar_t const * __ptr64 const>)+0xD4A (main.obj)
002E89D8   Far.exe!`wmain_seh(void)'::`2'::<lambda_1>::operator()(void)const __ptr64+0x38 (main.obj)
...
003FD5B6   Far.exe!memcpy+0x126 (libvcruntime:memcpy.obj):
                           00007ff7`5aafd5a3 c3              ret
                           00007ff7`5aafd5a4 0fb60a          movzx   ecx,byte ptr [rdx]
                           00007ff7`5aafd5a7 8808            mov     byte ptr [rax],cl
                           00007ff7`5aafd5a9 c3              ret
                           00007ff7`5aafd5aa 8b0a            mov     ecx,dword ptr [rdx]
                           00007ff7`5aafd5ac 8908            mov     dword ptr [rax],ecx
                           00007ff7`5aafd5ae c3              ret
                           00007ff7`5aafd5af 90              nop
                           00007ff7`5aafd5b0 4983f820        cmp     r8,20h
                           00007ff7`5aafd5b4 7717            ja      Far+0x3fd5cd (00007ff7`5aafd5cd)
                           00007ff7`5aafd5b6 f30f6f0a        movdqu  xmm1,xmmword ptr [rdx]
...
----------------------------------------------------------------------
Registers
----------------------------------------------------------------------
RAX = 000001CAE86D7400
RBX = 0000000000000000
RCX = 000001CAE86D7400
RDX = 0000000000000000
RSI = 0000000000000001
RDI = 0000000000000000
R8  = 0000000000000020
R9  = 0000000000000005
R10 = 00007FF75A700000
R11 = 000001CAE86D7400
R12 = 0000000000000001
R13 = 000001CAE86D7400
R14 = 000001CAE8608A60
R15 = 0000000000000000
RIP = 00007FF75AAFD5B6
RSP = 000000A9485BE858
RBP = 0000000000000001
EFL = 00010246

I'm not ASM guru. It seems RIP points to movdqu xmm1,xmmword ptr [rdx]. This instruction copies the memory into the CPU register. Looks like the source buffer address is incorrect. Or the amount of bytes to copy is incorrect.

alabuzhev commented 1 year ago

Maybe if you still have the FAR.pdb file you can open it and examine the passed arguments.

I did and I know where it crashed, but, as I said, it is hard to do something sensible here:

you have a damaged font
the OS failed to initialize the console window properly
Far couldn't get the window dimensions and didn't allocate the screen buffer
The code in the call stack tried to do things, assuming that the buffer is there, and dereferenced a null pointer.

I suppose I can patch up this particular place, but it will likely crash again a few instructions later - there are assumptions all over the place that the window has some reasonable dimensions.

ujos commented 1 year ago

OK. As far as OS does not work as expected, then this bug is on the Microsoft side.

The best thing we can do I believe is to show a MessageBox with the message, why FAR is unable to start.

alabuzhev commented 1 year ago

Yes, except that MessageBox is evil in our case - there is always a chance that we are running in ssh/telnet.

FarGroup / FarManager