I have the following system configuration:
Windows 2008 Server 64-bit with Service Pack 1
Gpg4win, version 2.1.0
Included Gpg4win components in Version 2.1.0 are:
GnuPG: 2.0.17
Kleopatra: 2.1.0 (2011-02-04)
GPA: 0.9.1-svn1024
GpgOL: 1.1.2
GpgEX: 0.9.7
Claws-Mail: 3.7.8cvs47
Kompendium DE: 3.0.0
Kompendium EN: 3.0.0-beta1
What I'm trying to do is to decrypt a local file using GnuPG with Process.Start from a .NET 3.5 web service.
This command below is working just fine when ran from cmd.exe on that very machine.
"c:\Program Files (x86)\GNU\GnuPG\pub\" --charset utf8 --no-tty --output c:\decrypted_file.txt" --batch -r "name_for_secret_key"
--passphrase-file "C:\path_to_passphrase_file.txt"
--decrypt "c:\encrypted_file.gpg"
However it's not working when executed from the web service that is deployed under IIS 7.5.
Tried the following:
- impersonated user with admin rights (in the application pool or in the code itself) to run the process under
- ran the cmd.exe process directly with Process.Start and passed in the arguments as described above (by redirecting standard input)
Results
- exit code for gpg2.exe is 255 and nothing else happened
- in event viewer / application found errors like: Faulting application gpg2.exe, version 0.0.0.0, time stamp 0x4d6e6194, faulting module unknown, version 0.0.0.0, time stamp 0x00000000, exception code 0xc0000005, fault offset 0x00000000, process id 0x1a914, application start time 0x01cd3f46059b0031.
- by redirecting standarderror I only got the same 255 exit code
- ran Process Monitor on that machine but that hasn't helped either, there were some "Name Not Found" issues, no access denied problems and both gpg.exe and gpg2.exe results were SUCCESS and exit codes were 255.
- DEP has default settings, it's on on essential windows programs and services
Could you think of something different than what I've already tried which might get this working?
Related
Starting 2020-12-09, VSCode's Rust Analyzer extension no longer loads for me. On launch, it prints out this error message:
Cannot activate rust-analyzer: bootstrap error. See the logs in "OUTPUT > Rust Analyzer Client" (should open automatically). To enable verbose logs use { "rust-analyzer.trace.extension": true }
Enabling extension tracing produces the following diagnostic just before failing:
INFO [12/10/2020, 10:03:22 AM]: Using server binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: Checking availability of a binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe --version: {
status: 3221225506,
signal: null,
output: [ null, '', '' ],
pid: 1648,
stdout: '',
stderr: ''
}
where <user> is the name of the user account I use to log into the system1.
The status value reported in the error diagnostic (3221225506) translates to 0xC0000022 (STATUS_ACCESS_DENIED). Navigating to the binary from within VSCode's integrated terminal and trying to execute rust-analyzer-windows.exe --version doesn't produce any output, which seems to reinstate that running this executable from VSCode is somehow blocked.
It appears that something changed with respect to access rights executing the server binary from within VSCode. In between Rust Analyzer working and Rust Analyzer no longer working I didn't update Rust, nor rustup, nor VSCode, nor any extensions.
I did install 2020-12 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB4592438), though, and the time Rust Analyzer started failing coincides with the time the update got installed. That could literally just be a coincidence.
What additional steps can I take to get to the root cause of the issue, and how do I get Rust Analyzer working again?
Version information:
Rust Analyzer (stable): v0.2.408
Windows 10 Pro: Version 10.0.19042 Build 19042
VSCode: 1.51.1 (user setup)
1 This is also the user account VSCode runs under, including all of its spawned processes. Navigating to the path from a command prompt running under this account reveals that rust-analyzer-windows.exe is present, and executing rust-analyzer-windows.exe --version prints a version identifier, as expected.
Unfortunately, I didn't quite get to investigate the root cause of this.
A system reboot that was forced upon me appears to have restored World Peace.
Clearing proxy config works for me.
I'm not sure this covered all situation, but it might be related to the network.
Simply, I cannot run App verifier (WOW or 64-bit). It simply does not start. Event viewer says:
Faulting application name: appverif.exe, version: 10.0.18362.1, time stamp: 0x58ca3409
Faulting module name: ntdll.dll, version: 10.0.18362.1139, time stamp: 0x335bbdaf
Exception code: 0xc0000374
Fault offset: 0x000dfa1d
Faulting process ID: 0x2ad0
Faulting application start time: 0x01d6aa7ad4a12bf6
Faulting application path: C:\Windows\SysWOW64\appverif.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 235c3a4d-2d54-4436-99bf-b54a217c9a7f
Additionally, I tried to run appverif.exe (in system and syswow64) under Visual Studio and I see:
EDIT (Update based on comments)
Some are suggesting that Application Verifier does not have a GUI. However, last time I ran it, I saw the following:
I asked Microsoft employee Gov Maharaj (from application compatibility team) and they already know about the issue and the issue is fixed in an update for the Windows 10 2004 SDK which was released in December 2020 (19041.685.201201-2105.vb_release_svc_prod1_WindowsSDK.iso):
The Windows 10 SDK, Version 2004 SDK servicing update (released
12/16/2020) contains the following fixes. If you encounter these
issues, we recommend that you update your version of the SDK as soon
as possible to avoid them:
Resolved issue that prevented AppVerifier from working
Download and install the update to fix it.
I managed to run the verifier under a SYSTEM account using PsExec:
...PsTools\PsExec64.exe -i -s C:\Windows\System32\appverif.exe
I've tried the recommended methods - installing the latest windows SDK and running the program through 'PsExec64.exe -i -s' but neither worked. This program seems to be something Microsoft periodically breaks, judging by what I've read.
I ran appverif.exe through visual studio and saw the following call stack on crash:
ntdll.dll!RtlReportCriticalFailure() Unknown
ntdll.dll!RtlpHeapHandleError() Unknown
ntdll.dll!RtlpHpHeapHandleError() Unknown
ntdll.dll!RtlpLogHeapFailure() Unknown
ntdll.dll!RtlpFreeHeapInternal() Unknown
ntdll.dll!RtlFreeHeap() Unknown
msvcrt.dll!00007ffd44449c9c() Unknown
appverifUI.dll!00007ffc9a41f9d6() Unknown
appverifUI.dll!00007ffc9a411636() Unknown
appverif.exe!00007ff64965281b() Unknown
appverif.exe!00007ff6496615ed() Unknown
kernel32.dll!00007ffd43957034() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
It seems to be crashing after a heap free.
In trying to install the Epson JavaPOS ADK the program never finishes. Looking at the log file seems that the program is looking for files that do not exist, and therefore cannot manipulate them. After installation "completes" the file C:\opt\EpsonJavaPOS\Uninstall_Epson JavaPOS ADK_1.14.0.0\.com.zerog.registry is created. Not sure what I've done to mess this up.
Log exerpts
Modify Text File - Single File: No Target Chosen
Status: ERROR
Additional Notes: ERROR - Unable to locate ASCII text file to be manipulated. Deferring...
Modify Text File - Single File: No Target Chosen
Status: ERROR
Additional Notes: ERROR - Unable to locate ASCII text file to be manipulated. Deferring...
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Check Disk Space: /opt\EpsonJavaPOS
Status: SUCCESSFUL
Additional Notes: NOTE - Required Disk Space: 40,268,671; Free Disk Space: -1
Install Action: Jump To: Next Unit Package Con't -- Prev: NO JUMP
Status: SUCCESSFUL
Modify Text File - Single File: SetupPOS.properties
Status: ERROR
Additional Notes: ERROR - Unable to locate ASCII text file to be manipulated. Deferring...
System Setup
Windows 10
Java 1.8.181
JavaPOS ADK v1.14W
There are bug fixes that may be involved in JavaPOS ADK 1.14.3W.
[Bug fix]
- The bug is fixed that the installation of JavaPOS ADK fails in the latest Java VM on Windows10.
The latest version is 1.14.6 W, so please try it.
EPSON JavaPOS ADK (for Windows OS) Ver. 1.14.6W
for me, i found out that the installer does not play nicely with Java 8 and Windows 10. After I used Java 7 as the parameter for LAX_VM, it installed correctly. You may need to switch to another user if the installer keeps skipping installation steps though.
I am using some earlier build for Windows 64-bit downloaded form here:
dl.dropboxusercontent.com/u/63393258/osm2pgsql_testRelease.zip
from this website:
awcull.com/2015/09/30/postgis-osm2pgsql-windows.html
but it is crashing when I am importing large pbf with whole Europe downloaded from download.geofabrik.de/
I'm tired of this shit... I tried slim and non-slim mode, I tried modifying cache size, nothing worked so far. Our server has 32 GB of RAM.
Where can I download latest osm2pgsql build for Windows 64-bit? Alternatively which compiler do you suggest to make my own build on Windows Server 2012 64-bit. Thanks.
The command I run osm2pgsql last time it crashed was:
PS C:\OSM\rendering> osm2pgsql -U postgres -m -d osm -p osm -E 3857 -s -C 25000 -S C:\OSM\osm2pgsql\default.style C:\OSM\Data\europe-latest.osm.pbf
It crashed with standard Windows dialog saying "the application stopped blablabla" with details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: osm2pgsql.exe
Application Version: 0.0.0.0
Application Timestamp: 53ea21fd
Fault Module Name: ntdll.dll
Fault Module Version: 6.3.9600.18438
Fault Module Timestamp: 57ae642e
Exception Code: c00000fd
Exception Offset: 0000000000030d02
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: 33ad
Additional Information 2: 33ad00700702b0ab4dc632df7667ec82
Additional Information 3: 2ebb
Additional Information 4: 2ebbf5b91303f76c5b7f75f6255100fa
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=280262
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Now I'm trying without "-C" option but I bet it will crash again...
PS C:\OSM\rendering> osm2pgsql -U postgres -m -d osm -p osm -E 3857 -s -S C:\OSM\osm2pgsql\default.style C:\OSM\Data\europe-latest.osm.pbf
Necromancing.
The latest build (Continuous Integration) can always be found on AppVeyor.
You need to get the current build (or in history a historic build by the git-commit hash).
https://ci.appveyor.com/project/openstreetmap/osm2pgsql
=> Environment arch x64
=> Artifacts tab
=> Donwload osm2pgsql_Release_x64.zip
The link might break, so if it does, you need to google "appveyor osm2pgsql",
it should usually be the first result.
Download from gis.stackexchange
Here is the Github link
Here is the Hot-Installer reference.
I'm trying to serve a big number of small files with G-WAN (version 4.3.14, started with sudo on 64-bit Ubuntu 14.04.3). I start hammering it with requests over a single connection using wget to provide base URL and a file with a list of the URL suffixes. At some point, which is different for different runs, the gwan executable silently exits. There's no trace in the gwan log or in the site error log (I did change '_log' to 'log' to enable logging). The exit status code is 139. What does it mean? When I stop it with Ctrl-C the exit code is 130.
Is there a reference for the exit status codes? I cannot find any with Google.
First, Ubuntu 14.04.3 is very recent while G-WAN v4.3.14 is very old. Almost every new OS release introduces cincompatibilities that require patches and this is why we have to issue more recent releases for registered users. This explains the 'silent exits' that you are experiencing.
Second, process exits codes can be found this way:
./gwan -h
echo $?
0
Zero means no error, and any other value is an error (mixing system flags to be as informative as possible). That's why Ctrl+C returns 130: Control-C is fatal error signal 2, (130 = 128 + 2).