Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
After a number of updates had been applied to my laptop running Windows 8 Enterprise the system started displaying the following dialog box when attempting to launch a VirtualBox guest:
The VBoxStartup.log reports the following:
1560.22e4: VirtualBox.exe: timestamp 0x550706a7 (rc=VINF_SUCCESS)
1560.22e4: '\Device\HarddiskVolume4\Program Files\Oracle\VirtualBox\VirtualBox.exe' has no imports
1560.22e4: '\Device\HarddiskVolume4\Windows\System32\ntdll.dll' has no imports
1560.22e4: supR3HardNtChildPurify: Done after 593 ms and 0 fixes (loop #0).
1560.22e4: supR3HardNtEnableThreadCreation:
23c4.2198: Log file opened: 4.3.26r98988 g_hStartupLog=0000000000000004 g_uNtVerCombined=0x6223f000
23c4.2198: supR3HardenedVmProcessInit: uNtDllAddr=000007f8de8b0000
23c4.2198: ntdll.dll: timestamp 0x5507a832 (rc=VINF_SUCCESS)
23c4.2198: New simple heap: #1 0000000000840000 LB 0x400000 (for 1822720 allocation)
23c4.2198: System32: \Device\HarddiskVolume4\Windows\System32
23c4.2198: WinSxS: \Device\HarddiskVolume4\Windows\WinSxS
23c4.2198: KnownDllPath: C:\windows\system32
23c4.2198: supR3HardenedVmProcessInit: Opening vboxdrv stub...
23c4.2198: supR3HardenedWinReadErrorInfoDevice: 'ntdll.dll: 7981 differences between 0x300c and 0x4fff in #1 (.text), first: 4c != 1f'
23c4.2198: Error -5600 in supR3HardenedWinReSpawn! (enmWhat=3)
23c4.2198: NtCreateFile(\Device\VBoxDrvStub) failed: Unknown Status -5600 (0xffffea20) (rcNt=0xe986ea20)
VBoxDrvStub error: ntdll.dll: 7981 differences between 0x300c and 0x4fff in #1 (.text), first: 4c != 1f
1560.22e4: supR3HardenedWinCheckChild: enmRequest=2 rc=-5600 enmWhat=3 supR3HardenedWinReSpawn: NtCreateFile(\Device\VBoxDrvStub) failed: Unknown Status -5600 (0xffffea20) (rcNt=0xe986ea20)
VBoxDrvStub error: ntdll.dll: 7981 differences between 0x300c and 0x4fff in #1 (.text), first: 4c != 1f
1560.22e4: Error -5600 in supR3HardenedWinReSpawn! (enmWhat=3)
1560.22e4: NtCreateFile(\Device\VBoxDrvStub) failed: Unknown Status -5600 (0xffffea20) (rcNt=0xe986ea20)
VBoxDrvStub error: ntdll.dll: 7981 differences between 0x300c and 0x4fff in #1 (.text), first: 4c != 1f
The original solution was to uninstall Microsoft update KB3045999. The guest would launch as expected - no more issue.
Today however, after another set of Windows Updates was applied, the error has returned. This time KB3045999 doesn't seem to be installed.
Was KB3045999 rolled into a different update? Is there a better fix/work-around available?
I had a similar error, couldn't start any of my guest systems. After restarting Windows, Virtual box began to work normally.
I downloaded the latest version of VirtualBox (5.0.2) from https://virtualbox.org/wiki/Downloads, installed it and the guest launched as expected.
for me it was fixed by using test build "VirtualBox-5.0.15-105767-Win"
https://www.virtualbox.org/wiki/Testbuilds
Related
MacOS Ventura 13 does not work WSO2 Integration Studio 8 and 8.1.
After updating, Integration Studio no longer works, it is not even possible to update, because as soon as you open it, it closes.
Can anyone help?
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: IntegrationStudio [7330]
Path: /Applications/IntegrationStudio 8.1.0.app/Contents/MacOS/IntegrationStudio
Identifier: WSO2-Integration-Studio
Version: 8.1.0 (8.1.0.202203281342)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 502
Date/Time: 2022-11-21 03:13:23.5866 -0300
OS Version: macOS 13.0.1 (22A400)
Report Version: 12
Bridge OS Version: 7.0 (20P420)
Anonymous UUID: 62E89E18-244E-340C-9848-0286032B8D9E
Time Awake Since Boot: 11000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process: exc handler [7330]
When opening Integration Studio, chosen Workspace, the initial screen is displayed and closes.
It's not even possible to update the packages to see if it resolves.
Add the following line to your ~/.zprofile alias
alias is='/Applications/IntegrationStudio.app/Contents/Eclipse/jdk-home/Contents/Home/bin/java -XstartOnFirstThread -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true -Declipse.pde.launch=true --add-modules=ALL-SYSTEM -Dfile.encoding=UTF-8 -classpath /Applications/IntegrationStudio.app/Contents/Eclipse/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar org.eclipse.equinox.launcher.Main -launcher /Applications/IntegrationStudio.app/Contents/Eclipse/Eclipse.app/Contents/MacOS/eclipse -name Eclipse -showsplash 600 -product org.eclipse.platform.ide -os macosx -ws cocoa -arch x86_64 -nl en_GB'
Then open a new terminal and you should be able to enter 'is' and start Integration Studio. If you installed 8.1 you might have to go to System Settings-> Privacy & Security and allow the application to be run.
This works for me until WSO2 or Apple resolves the issue properly.
I am running into an issue with my solution that is comprised of a native C++ application calling a managed C++ (CLR) that is in turn referencing a C# project.
(Typical native to managed bridge implementation)
The code compiles and runs successfully on my development machine. However once I move it to a staging server I get the following error:
Faulting application name: POC_MOCK.exe, version: 0.0.0.0, time stamp: 0x62c75fef
Faulting module name: ucrtbase.DLL, version: 10.0.14393.2990, time stamp: 0x5caeb859
Exception code: 0xc0000409
Fault offset: 0x000884cb
Faulting process id: 0x1c9c
Faulting application start time: 0x01d8927e8d0fe66f
Faulting application path: D:\test\POC_MOCK.exe
Faulting module path: C:\Windows\SYSTEM32\ucrtbase.DLL
Report Id: cad1e77c-fe71-11ec-80fe-000c297ddf34
Faulting package full name:
Faulting package-relative application ID:
Upon investigating the crash dump via winDBG, I saw that ijwhost.dll is causing an exception.
STACK_TEXT:
00e2fc60 5e00c672 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x48
00e2fc90 5e001405 00e2fcb0 5e015750 00f58fe8 Ijwhost!_CxxThrowException+0x66
00e2fcdc 5e009d4c 013c0667 00000000 00f5dc20 Ijwhost!start_runtime_and_get_target_address+0x138
00e2fcf0 5e0b1fc5 c42602c1 00f5a430 00f5dc20 Ijwhost!start_runtime_thunk_stub+0xc
00e2fd10 01201041 9b12698d 73d9cf33 9b12698d CPPWrapper!CPPWrapper::CPPWrapper+0x45
00e2fd30 0120159c 00000001 00f5a430 00f58fe8 POC_MOCK!main+0x41
00e2fd78 74bd6a14 7f218000 74bd69f0 eefe366c POC_MOCK!__scrt_common_main_seh+0xfa
00e2fd8c 7712a9ff 7f218000 ed2f7874 00000000 kernel32!BaseThreadInitThunk+0x24
00e2fdd4 7712a9ca ffffffff 7710fdc7 00000000 ntdll!__RtlUserThreadStart+0x2f
00e2fde4 00000000 01201624 7f218000 00000000 ntdll!_RtlUserThreadStart+0x1b
FAULTING_SOURCE_LINE: D:\a\_work\1\s\src\installer\corehost\cli\ijwhost\ijwthunk.cpp
FAULTING_SOURCE_FILE: D:\a\_work\1\s\src\installer\corehost\cli\ijwhost\ijwthunk.cpp
FAULTING_SOURCE_LINE_NUMBER: 153
FAULTING_SOURCE_CODE:
No source found for 'D:\a\_work\1\s\src\installer\corehost\cli\ijwhost\ijwthunk.cpp'
SYMBOL_NAME: ijwhost!start_runtime_and_get_target_address+138
MODULE_NAME: Ijwhost
IMAGE_NAME: Ijwhost.dll
STACK_COMMAND: .cxr 0xe2f920 ; kb
FAILURE_BUCKET_ID: FAIL_FAST_FATAL_APP_EXIT_CPP_EXCEPTION_c0000409_Ijwhost.dll!start_runtime_and_get_target_address
OS_VERSION: 6.3.9600.18217
BUILDLAB_STR: winblue_ltsb
OSPLATFORM_TYPE: x86
OSNAME: Windows 8.1
IMAGE_VERSION: 5.0.1722.21314
FAILURE_ID_HASH: {b2047410-307d-cb83-9a4d-78b763edf2d5}
Followup: MachineOwner
I have no idea why Ijwhost::start_runtime_and_get_target_address is failing.
This seems to be a bit different than most of the issues I was able to find via google and on StackOverflow, so having tried some of the suggestions there didn't work for me.
ijwhost.dll does exist after a successful build and is next to the .EXE and .DLLs.
As seen in the above stack trace, the issue is happening when CPPWrapper is being constructed, and I took out all the references to anything C# and still got the error.
So just trying to call the constructor of the CLR DLL is where it goes bad.
Any hints, feedback is greatly appreciated!
Dev. evn.:
Win 10 professional, VS2022, VC++ v143, .NET6 and .NetCore 3.1
Staging env.:
Win Server 2012, required packages installed for the project to work and confirmed .net core 3.1 is installed for both x86 and x64 to be on the safe side.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 28 days ago.
Improve this question
I am compiling LLVM and Clang from source but getting the following error when it tries to link lib/libclang-cpp.so.14git:-
/usr/bin/ld.gold: internal error in open, at ../../gold/descriptors.cc:99
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
I am using Gold Linker and my GCC version is 9.3.0. The LLVM branch is that of LLVM-12 (llvmorg-12.0.0). Earlier I was using LLD linker but that was causing memory overflow, after switching to Gold memory does not overflow but it still fails.
System specs:-
16GB RAM
512GB NVMe SSD
i7 10th Gen 8-cores
Also my swap size is 4GB. I have tried using lesser cores too, but the error still persists.
Any help would be appreciated. Thanks.
P.S:- I am an absolute noob when it comes to LLVM.strong text
I finally figured this out. I was getting the same error, but building a different project.
Turns out that gold is bad at reporting errors. The actual issue is that the OS is running out of file descriptors. In my case it was set to 1024 (you can check with ulimit -n) but a large linking job needed more than that.
If you bump the number of file descriptors then gold works just fine.
# I choose 65536, you can change this number
ulimit -n 65536
Why do I say gold is bad at reporting errors? Because if you force it to run on multithreaded mode (it defaults to single threaded) then it properly reports:
/usr/bin/ld.gold: fatal error: out of file descriptors and couldn't close any
Which is a more useful message.
My Windows 7 was upgraded to Windows 10 a week ago. Before the upgrade, my NetBeans IDE 8.0.2 with C/C++ plugin worked fine with C++ programs. However, after the Windows 10 upgrade, it cannot build/make C++ programs any more, with the error message below. Note that the Java plugin still works fine, and the C++ editor part is still OK too. The C/C++ Tool Collection is 64-bit Cygwin.
Any clue on what caused this specifically, and any solution on fixing this?
===== Complete Error Message Below: =====
4 [main] make 5900 C:\cygwin64\bin\make.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
15248 [main] make 5900 cygwin_exception::open_stackdumpfile: Dumping stack trace to make.exe.stackdump
9 [main] make 4464 fork: child -1 - forked process 5900 died unexpectedly, retry 0, exit code 0x100, errno 11
make: nbproject/Makefile-variables.mk:33: fork: Resource temporarily unavailable
43162 [main] make 2164 C:\cygwin64\bin\make.exe: *** fatal error in forked process - fork: can't reserve memory for parent stack 0x600000 - 0x800000, (child has 0x400000 - 0x600000), Win32 error 487
43898 [main] make 2164 cygwin_exception::open_stackdumpfile: Dumping stack trace to make.exe.stackdump
3943868 [main] make 4464 fork: child -1 - forked process 2164 died unexpectedly, retry 0, exit code 0x100, errno 11
make: fork: Resource temporarily unavailable
BUILD FAILED (exit value 2, total time: 9s)
I'm trying to read the MCUs ADC register using GDB but I can't seem to find how it's done.
Using x\10x 0x40012708 in gdb just returns zeroes, as do any memory mapped peripheral register I try to read.
It this possible to do? If so, how is it done?
Thanks!
I would suggest to validate that your setup is functional first.
For example, you could try to read the CPUID register which is present on all Cortex-M0 processors - see section 4.3 of the Cortex™-M0 DevicesGeneric User Guide.
It is located at address 0xE000ED00, and it shall contain value 0x410CC200.
If you can read it, this would be a good sign.
You probably should try using J-Link commander first, then with GDB-Server and GDB. I ran the procedure hereafter on an Olimex board using an LPC1114/301 Cortex-M0. I was using J-Link software V5.10n, and arm-none-eabi-gdb version 7.10.1.20151217-cvs, which is part of Linaro gcc 5.2 for ARM Cortex-M processors package.
Start JLink.exe using the following options:
jlink.exe -if SWD -speed 4000 -AutoConnect 1 -device Cortex-M0
You should see something similar to:
SEGGER J-Link Commander V5.10n (Compiled Feb 19 2016 18:39:46)
DLL version V5.10n, compiled Feb 19 2016 18:39:11<br/>
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: [My J-Link EDU Serial Number]
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.313V
Device "CORTEX-M0" selected.
Found SWD-DP with ID 0x0BB11477
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl 0 # E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
J-Link>
You can now read the CPUID register using the J-Link commander mem32 command, and verify the CPUID register does contain the expected value:
J-Link>mem32 0xE000ED00,1
You should get:
E000ED00 = 410CC200
If this is the case, I would say that your J-Link/Cortex-M0 setup is likely functional. We can now verify GDB Server and GDB are working fine too.
Launch JLinkGDBServerCL.exe with the following options: JLinkGDBServerCL.exe -if SWD -speed 4000 -device Cortex-M0
SEGGER J-Link GDB Server V5.10n Command Line Version
JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Cortex-M0
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: [My J-Link EDU Serial Number]
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Keep the GDB server running, and start GDB in an other Windows console session:
arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
We can now connect to GDB server, and attempt to display the content of the CPUID register again:
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0xfffffffe in ?? ()
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) x/1xw 0xE000ED00
0xe000ed00: 0x410cc200
(gdb)
If you are getting 0x410cc200 again, your J-Link/Cortex-m0/GDB Server/GDB setup should be functional, and you should now try again to read your ADC register using this command:
x/1xw 0x40012708
If you were able to read the CPUID register, but not the ADC register, and if the address for the ADC register is correct, I would not have an explanation for this behavior right now - knowing the exact brand/model for the MCU you are using could of course help further.
Please note that from now on, you should specify the exact model for your MCU as the argument to the -device J-Link Commander/GDB Server options instead of Cortex-M0. You can get the list by entering command ? on the J-Link Commander command-prompt.