Finally, I found the reason of the problem. It is the latest version problem of 'rustc' program.
From the v1.83, the "STATUS_ACCESS_VIOLATION" error came out when I try to build the "hello" sample code. Below v1.82, it's OK, no problem to build and run the code.
ver 1.81 --> OK
ver 1.82 --> OK
ver 1.83 --> Error
ver 1.84 --> Error
My computer spec is:
Processor: 11th Gen Intel(R) Core(TM) i7-11600H @ 2.90GHz 2.92 GHz
OS: Win 11 v21H2
The reason why I couldn't find this problem before is that I used wrong command to downgrade the 'rustc' version.
I did wrong way to downgrade the version: rustup install 1.81
The right way to downgrade the version: rustup default 1.81
--> I didn't know this command, so I thought I downgraded the version and tested it.
Therefore, though I re-installed the Windows and re-installed Rust using rustup-init.exe, the latest version of Rust was installed in my PC, and it caused the problem.
I didn't know this and thought the problem was with the company's DRM software. That's because I had the same problem when I installed Rust on another PC. But the problem was with the latest version. The other PC was the same model of laptop, but I had installed the latest version of Rust using rustup_init.exe, which caused the problem.
Below is my test result according to the 'rustc' version:
It would probably be useful for troubleshooting to capture the crash in a debugger. VS or WinDbg will work. It will give you more detailed information about the cause of the crash.
I changed default Rust version to v1.84 and made a 'Error condition' and dumped using WinDbg by commanding "cargo build". Below is the dump, but I couldn't analyse it.
Microsoft (R) Windows Debugger Version 10.0.27725.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: cargo build
Starting directory: d:\tmp\testa
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
+------------------------------------------------------------------------+
| This target supports Hardware-enforced Stack Protection. A HW based |
| "Shadow Stack" may be available to assist in debugging and analysis. |
| See aka.ms/userhsp for more info. |
| |
| dps @ssp |
| |
+------------------------------------------------------------------------+
ModLoad: 00007ff6`6f060000 00007ff6`6f8ee000 rustup_init.exe
ModLoad: 00007ffb`4eca0000 00007ffb`4eeaa000 ntdll.dll
ModLoad: 00007ffb`4cb00000 00007ffb`4cbbd000 C:\Windows\System32\KERNEL32.DLL
ModLoad: 00007ffb`4c340000 00007ffb`4c6c5000 C:\Windows\System32\KERNELBASE.dll
ModLoad: 00007ffb`4e1a0000 00007ffb`4e251000 C:\Windows\System32\advapi32.dll
ModLoad: 00007ffb`4e440000 00007ffb`4e4e3000 C:\Windows\System32\msvcrt.dll
ModLoad: 00007ffb`4dae0000 00007ffb`4db81000 C:\Windows\System32\sechost.dll
ModLoad: 00007ffb`4cac0000 00007ffb`4cae7000 C:\Windows\System32\bcrypt.dll
ModLoad: 00007ffb`4e6f0000 00007ffb`4e811000 C:\Windows\System32\RPCRT4.dll
ModLoad: 00007ffb`4dc80000 00007ffb`4de1a000 C:\Windows\System32\ole32.dll
ModLoad: 00007ffb`4c100000 00007ffb`4c19d000 C:\Windows\System32\msvcp_win.dll
ModLoad: 00007ffb`4c750000 00007ffb`4c861000 C:\Windows\System32\ucrtbase.dll
ModLoad: 00007ffb`4e550000 00007ffb`4e579000 C:\Windows\System32\GDI32.dll
ModLoad: 00007ffb`4c310000 00007ffb`4c336000 C:\Windows\System32\win32u.dll
ModLoad: 00007ffb`4c870000 00007ffb`4c98c000 C:\Windows\System32\gdi32full.dll
ModLoad: 00007ffb`4e820000 00007ffb`4e9cc000 C:\Windows\System32\USER32.dll
ModLoad: 00007ffb`4de20000 00007ffb`4e196000 C:\Windows\System32\combase.dll
ModLoad: 00007ffb`4e580000 00007ffb`4e656000 C:\Windows\System32\oleaut32.dll
ModLoad: 00007ffb`4c1a0000 00007ffb`4c302000 C:\Windows\System32\crypt32.dll
ModLoad: 00007ffb`4d510000 00007ffb`4d57f000 C:\Windows\System32\ws2_32.dll
ModLoad: 00007ffb`4cbc0000 00007ffb`4d386000 C:\Windows\System32\shell32.dll
ModLoad: 00007ffb`4b990000 00007ffb`4b99c000 C:\Windows\SYSTEM32\CRYPTBASE.DLL
(3e9c.31ac): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffb`4ed7cb44 cc int 3
0:000> .dump /ma "d:\tmp\cargo_build.dmp"
Creating d:\tmp\cargo_build.dmp - mini user dump
Dump successfully written
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\atlmfc.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\concurrency.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\cpp_rest.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\ObjectiveC.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\stl.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\Windows.Data.Json.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\Windows.Devices.Geolocation.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\Windows.Devices.Sensors.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\Windows.Media.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\windows.natvis'
NatVis script unloaded from 'C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2410.11001.0_x64__8wekyb3d8bbwe\amd64\Visualizers\winrt.natvis'
************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
EnableRedirectToChakraJsProvider : false
-- Configuring repositories
----> Repository : LocalInstalled, Enabled: true
----> Repository : UserExtensions, Enabled: true
>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds
************* Waiting for Debugger Extensions Gallery to Initialize **************
>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.031 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 42
Microsoft (R) Windows Debugger Version 10.0.27725.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\tmp\cargo_build.dmp]
User Mini Dump File with Full Memory: Only application data is available
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 22000 MP (12 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 22000.1.amd64fre.co_release.210604-1628
Debug session time: Mon Jan 13 16:12:31.000 2025 (UTC + 9:00)
System Uptime: 2 days 9:15:04.846
Process Uptime: 0 days 0:00:46.000
......................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
+------------------------------------------------------------------------+
| This target supports Hardware-enforced Stack Protection. A HW based |
| "Shadow Stack" may be available to assist in debugging and analysis. |
| See aka.ms/userhsp for more info. |
| |
| dps @ssp |
| |
+------------------------------------------------------------------------+
For analysis of this file, run !analyze -v
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffb`4ed7cb44 cc int 3
0:000> dx Debugger.Sessions[0].Processes[1476].Threads[19032].Stack.Frames[0].SwitchTo();dv /t /v
Debugger.Sessions[0].Processes[1476].Threads[19032].Stack.Frames[0].SwitchTo()
Unable to enumerate locals, Win32 error 0n87
Private symbols (symbols.pri) are required for locals.
Type ".hh dbgerr005" for details.
That looks like a breakpoint inserted at the start of the executable. Try g to continue execution and then k when it breaks again on what should be the location of the crash.
I did it at home, b/c my laptop at home push the same error. Below is the log in the WinDbg, I gave 'g' command once and the error came out, after then I typed 'k' command.
Looks like the debugger is attached to rustup, not the rustc process that crashes. Can you run the command that cargo reports as crashing in the debugger? I think that would be C:\Users\hj7.park\.rustup\toolchains\1.84-x86_64-pc-windows-msvc\bin\rustc.exe --crate-name test1 --edition=2021 src\main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=119 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --check-cfg cfg(docsrs) --check-cfg "cfg(feature, values())" -C metadata=3818258f0814ea6f --out-dir D:\tmp\test1\target\debug\deps -C incremental=D:\tmp\test1\target\debug\incremental -L dependency=D:\tmp\test1\target\debug\deps.
instead of launching the program inside the debugger, maybe it's more convenient to set windbg as the jit debugger so it will automatically attach to the crashed process. e.g.:
Z:\> windbg -I
Z:\> cargo build
note, for the first command, the flag is an upper case I. to quote the documentation:
After this action is attempted, a success or failure message is displayed. If S is included, this procedure is done silently if it is successful; only failure messages are displayed.
The -I parameter must not be used with any other parameters. This command will not actually start WinDbg, although a WinDbg window may appear for a moment.
looks like @Coding-Badly was right, code was injected to the compiler process (probably every processes on the system).
searching the module name PAPERPHK64 didn't give many results, with conflicting information about what it actually is, but it's not a crash caused by rustc itself.
one source indicates it comes from some kind of secure printing software published by some " LI TECH Co., LTD":
but another source identifies it as " Trojan.Siggen28.41565":
Yup. Not my first rodeo. I've been on all sides of that: Writing injection code. Debugging my own injection code. Dealing with buggy 3rd party injection code.
Thank you for your perseverance and contributions!
Instead of removing it you may be able to temporarily cripple it by renaming the DLL (before starting rustc). If that works just remember to restore the name when you finish.
Yes, I think so.
In our company, there are a few security program such as 'incops3', 'SecuPrint' etc.
According to the log, I found 'PAPERPHK64.DLL' is called after 'System32\shcore.dll' and I found the 'System32\shcore.dll' is newly modified at the time that I installed the Security software.
Therefore, we can assume, the SecuPrint program replace ' System32\shcore.dll' and it can call PAPERPHK64.dll during the time of 'rustc' is runned.
A couple of other security software products also seem affected, including one from Samsung and one from Jiangsu Agile Technology. There may also be others that are not yet known.
