opening "Android adb cmd prompt" from inside Visual Studio crashes cmd.exe

[MagicAndre1981]

I use the Proof of Concept 3 version and copied the files to old clink install folder and replaced all files. Now the normal cmd worked, but as I use the android cmd often, I reverted to clink from martin.

Here is command line of android prompt:

"C:\Windows\System32\cmd.exe" /K cd "C:\Program Files (x86)\Android\android-sdk" & set PATH=%PATH%;"C:\Program Files (x86)\Android\android-sdk\platform-tools"

You can get the standalone platform tools without Xamarin workload of VS to repro and debug it.

[chrisant996]

I believe that you're experiencing a crash, and I want to track it down and resolve it!

However, I can't reproduce the crash using the stated steps:

1. I installed the standalone platform tools.
2. I installed PoC3 version of Clink.
3. I used \tmp\poc3\clink autorun install to set up autorun.
4. I used start "test" "C:\Windows\System32\cmd.exe" /K cd "C:\tmp\android sdk" & set PATH=%PATH%;"C:\tmp\android sdk\platform-tools" to start the indicated android command prompt.

Result: a new cmd prompt started successfully and seems fully functional; no crash.

Maybe copying the new clink 1.1.x over top of an existing 0.4.x installation is the problem, or maybe some specific lua scripts from the 0.4.x installation are exposing a problem in 1.1.x.

Can you please provide more information?

• Ideally a callstack or minidump of the crash itself.
• Can you share a copy of the clink installation (incl lua scripts and inputrc and clink_settings) that are used to reproduce the crash?

[chrisant996]

@MagicAndre1981 can you confirm that the adb cmd prompt runs as 32 bit?

A crash has been present in v1.0.0 and higher 32 bit Clink for years.

My guess is probably 32 bit Clink is getting launched:

• Probably the Android SDK IDE is a 32 bit application, which would force 32 bit Clink to be used.
• Or maybe the OS is 32 bit.

Either would also explain why I couldn't reproduce the problem: my OS is 64 bit, and installing the standalone tools means there's no 32 bit IDE, so when I followed the repro steps it launches 64 bit Clink.

[MagicAndre1981]

as VS201x is a 32bit process, the opened cmd is also 32bit

when I opened cmd standalone from my 64 bit file manager (altap salamander), the cmd.exe is also 64bit and here I get no crash

[chrisant996]

Problem 1: In 2017 the Clink injection code got changed so it crashes in 32 bit.
Also, premake needed to turn off runtime checks for clink_process, otherwise the injected lambda is not self-contained on 32 bit and thus crashes.

[chrisant996]

Problem 2: Clink initialization relies on CMD calling GetStdHandle.
32 bit CMD doesn't call that early enough during inject, so initialization didn't get triggered until after pressing Enter again. Changed to use a reliable API hook.

Problem 3: Cannot hook ReadConsoleW in 32 bit cmd.exe.
Clink fails to initialize and ends up behaving the same as CMD but without any prompt text.
This regression was introduced in clink/dll/shell_cmd.cpp in 304e8a3 on 2015/04/21.

[chrisant996]

Fixed by 03320a2 and 86ced1b.

[MagicAndre1981]

thanks for the fix, will try next Proof of Concept version

[MagicAndre1981]

the latest version still crashes cmd.exe (yes it crashes cmd.exe):

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Read

    Key  : Analysis.CPU.Sec
    Value: 1

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 41

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 75

    Key  : Analysis.System
    Value: CreateObject

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 2379

    Key  : Timeline.Process.Start.DeltaSec
    Value: 11


NTGLOBALFLAG:  0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

CONTEXT:  (.ecxr)
eax=00000000 ebx=01200130 ecx=57c3a172 edx=03d4fb34 esi=03d4fb80 edi=01200000
eip=01200131 esp=03d4fb7c ebp=74890419 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
01200131 2389740000f8    and     ecx,dword ptr [ecx-7FFFF8Ch] ds:002b:4fc3a1e6=????????
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 01200131
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 4fc3a1e6
Attempt to read from address 4fc3a1e6

PROCESS_NAME:  cmd.exe

READ_ADDRESS:  4fc3a1e6 

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%p verwies auf Arbeitsspeicher bei 0x%p. Der Vorgang %s konnte im Arbeitsspeicher nicht durchgef hrt werden.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  4fc3a1e6

IP_ON_HEAP:  01200131
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may
contain the address if it were loaded.

STACK_TEXT:  
WARNING: Frame IP not in any known module. Following frames may be wrong.
03d4fb80 772266ed 01200130 54175aae 00000000 0x1200131
03d4fbdc 772266bd ffffffff 772453eb 00000000 ntdll!__RtlUserThreadStart+0x2f
03d4fbec 00000000 01200000 01200130 00000000 ntdll!_RtlUserThreadStart+0x1b


SYMBOL_NAME:  ntdll!__RtlUserThreadStart+2f

MODULE_NAME: ntdll

IMAGE_NAME:  ntdll.dll

STACK_COMMAND:  ~4s ; .ecxr ; kb

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_ntdll.dll!__RtlUserThreadStart

OS_VERSION:  10.0.17763.1

BUILDLAB_STR:  rs5_release

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 10

[chrisant996]

the latest version still crashes cmd.exe (yes it crashes cmd.exe):

Doh! I didn't do thorough enough testing, that's embarrassing.

• The 32 bit debug build, 64 bit debug build, and 64 bit final build all worked.
• But the 32 bit final build still crashed, due to a fourth bug.

Commit 424df27 in Nov 2017 lost the __stdcall modifier and introduced a calling convention mismatch.

Should be fixed for real in the next PoC release.

[chrisant996]

Fixed by 7de2c4a. For real this time.

(Or at least, it's definitely working reliably now in both 32 and 64 bit on 4 of my computers 😜.)

[MagicAndre1981]

Fixed by 7de2c4a. For real this time.

yes, I can confirm this. Cmd no longer crashes: