I'm trying to create a simple (software) driver using these instructions.
Host is Windows 7 x64 with fully updated MSVS Express 2013.
Latest windows driver kit is installed and working fine.
A virtual machine also with Windows 7 x64 is succesfully provisioned by VS, and configured exactly following these instructions.
The deployment process seems to execute properly and the build log shows something like:
1> Catalog generation complete.
1> <snip>\Win7Debug\Driver Package\driver.cat
1> Done Adding Additional Store
1> Successfully signed: <snip>\Win7Debug\Driver Package\driver.cat
1>
1> Deploying driver files for project "<snip>\Driver Package\Driver Package.vcxproj". Deployment may take a few minutes...
2>------ Deploy started: Project: Driver, Configuration: Win7 Debug Win32 ------
2> Done Adding Additional Store
2> Successfully signed: <snip>\Win7Debug\Driver.sys
2>
3>------ Deploy started: Project: Driver Package, Configuration: Win7 Debug Win32 ------
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Deploy: 2 succeeded, 0 failed, 0 skipped ==========
However, when Visual Studio tries to start a debug session, I receive the following error message:
Unfortunately, there's no mention of which file it can't find. I've tried attaching a debugger and hooking kernel32's MessageBox so that maybe I could check the call trace / see which file it is looking for, but VS doesn't like me attaching ollydbg and it brings up a whole lot of other issues.
I've also tried Process Monitor to see what file it is trying to access but it's pretty hard to wade through everything it is doing.
Am I missing something? Anyone can point me in the right direction?
edit1: Did a clean install of both the host as target machine. Followed instructions perfectly: exact same error. Has nobody come across this before?
So the answer is that Visual Studio defaults to Kernel Debugger rather than Remote Debugger. Changing this at least got it to deploy and install the driver, but still caused the build process to hang forever.
I've given up on trying to write a KMDF driver and will instead opt for a global hook via SetWindowsHookEx instead. Not something I preferred, but the process for writing a kernel mode driver in Windows is way too tedious in my eyes.
Related
Installation vscode
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
It seems like the official Microsoft build should be obtained via the snap store:
sudo snap install code --classic
And the program looks normal. I can install plug-ins, create a new file et cetera.
Problem
However, I cannot open any files or projects. Doing so results in vscode crashing. I read that code --disable-gpu could solve this problem, but doesn't do so for me.
Any ideas
what may cause this crash?
or how to get the pacman vscode working?
Logs
$ code --verbose
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
Gtk-Message: 22:59:19.805: Failed to load module "canberra-gtk-module"
(code:33833): GdkPixbuf-WARNING **: 22:59:19.817: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[33863:1104/225919.911481:ERROR:appcenter_api.cc(52)] expecting appcenter url prefix
[main 2020-11-04T21:59:19.960Z] Sending env to running instance...
[main 2020-11-04T21:59:20.041Z] Sent env to running instance. Terminating...
[main 2020-11-04T21:59:20.041Z] Lifecycle#kill()
where the recommended gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache results in bash: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache: No such file or directory
I'm running Arch Linux (Manjaro) and installed vscode with:
sudo pacman -S code
but then a simple .NET core program resulted in
--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (clrdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
I had the same issue trying to get the debugger to work and I spent hours on finding the reason for this. What I found out is that the debugger only works with officially signed Microsoft binaries of VSCode. So you have to make a distinction here:
The package code contains the open source version of visual studio code, a build wich anyone can make using the provided sources by Microsoft. The program which you get here is therefore not signed by MS!
The package visual-studio-code-bin provided by the AUR contains a officially signed version by MS. If you use this package, the debugger works as expected.
I do not know wether snap - which I personally never used at all - provides this kind of package, so I can not tell anything about that, but using the said package from the user repository solved the problem for me reliably.
Try this one (which I installed just yesterday under the recent manjaro distribution and it worked fine) and see if this solves your problem with opening files and folders.
I'm trying to compile boost 1.66.0 on my Windows machine. I've got Visual Studio 2017 (Community) installed as my IDE and the 14.1 compiler definitely works. However, if I try to invoke this inside any of the VC2017 native command prompts
.\bootstrap
.\b2 variant=debug,release link=shared,static threading=single,multi address-model=64 toolset=msvc-14.1
I get plenty of the following errors:
'cl' is not recognized as an internal or external command, operable
program or batch file
If I change the toolset to msvc-14.0 everything works fine. I've also compiled boost 1.65.1 with msvc-14.1 sucessfully. However, there have been a number of Visual Studio updates since then.
Edit: I've tried compiling boost 1.65.1 again with the most recent compiler version (19.12.25834) and I get the same issue now. Calling "cl" manually inside the "x64 Native Tools Command Prompt for VS 2017" works fine though.
My solution was to:
Delete "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd"
Build again
My assumtion of reason: Boost makes a temporary "cmd" file which might be from an old build that did not support "msvc-14.1". The file is not rebuilt/deleted.
Background:
I had the same issue with one of my two development machines, both very similar (Windows 7) and updated with VC2017.3. The one working complained about the "Unknown version" (_MSC_VER=1911), but completed the building. The failing one had the "cl is not recognized" error. When looking at the point of failure it explicitly said that it was calling "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd".
I did a compare at both machines and found that the failing one did not include setting __VSCMD_PREINIT_VCToolsVersion=14.12.25827. There might have been other differences but this one was for sure.
I assumed that I was missing some SW packages or environment settings, but found it strange that the file was not deleted when doing a "b2.exe --toolset=msvc-14.1 --clean-all".
My solution was to delete the temporary cmd file - allowing it to be rebuilt.
After manually deleting "c:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd", the building worked fine (except for the 1.65.1 complains about the version _MSC_VER=1911).
my webstorm debugger works fine if I simply run, say, my server.js directly in debug mode.
However, when I run an NPM script in debug mode (npm start for instance), I get the following exception:
Process finished with exit code -1073741510 (0xC000013A: interrupted by Ctrl+C)
I use Webstorm WebStorm 2016.1.2
Build #WS-145.971, built on May 1, 2016
JRE: 1.8.0_77-b03 x86
JVM: Java HotSpot(TM) Server VM by Oracle Corporation
My Node version is 5.11.0
I run it Windows 7, my colleague is running Windows 10 with same problem.
Did anyone come across this problem yet?
there could be many reasons for this - here are just some of my thoughts which may be useful to someone:
maybe some problem of the IDE: e.g. in this case caused by old watch variables
try to clear the ide/debugger state: e.g. delete breakpoints, watches, etc.
try: Invalidate caches / Restart
maybe just an early exit
I had one case in our node-tests, where some part of the code just called process.exit(0) before the async test-function had finished. This also caused the (confusing) console output:
Process finished with exit code -1073741510 (0xC000013A: interrupted by Ctrl+C)
I've recently loaded the new Android dev tools, SDK 20130717 and NDK r9.
Up to now I had the previous versions, working and debugging from within Eclipse just fine on both of my systems, a XP and a W7/64.
Now, the W7/64 with the new tools does work and debug my apps ok after the new tools installation and the required path environment changes.
It works ok when I select the "Debug As" + "Android Native Application".
Yet the XP, although they have the exact configuration in terms of folders/cygwin etc, after the new tools installed and the necessary path env changed, it looks that it can't start the ndk-dbg and it;s stuck waiting in definitively at "Launching MyApp(1): (100%)".
That happens after I select the "Debug As" + "Android Native Application".
Any hints on what might be the cause of it? or
is there any known issue on XP and r9 debugging that I miss?
thanks,
Christos
*edit
Tried to start manually the ndk-gdb and this is what I get, any hints are welcome
Blockquote
$ ndk-gdb --start --verbose --force
Android NDK installation path: /cygdrive/e/android-ndk-r9
Using default adb command: /cygdrive/e/adt-bundle-windows-x86-20130717/sdk/platform-tools/adb
ADB version found: Android Debug Bridge version 1.0.31
Using ADB flags:
Using JDB command: /cygdrive/e/Android/Java/jdk1.7.0_21/bin/jdb
Using auto-detected project path: .
Found package name: myndkpackage
ABIs targetted by application: armeabi-v7a
Device API Level: 17
Device CPU ABIs: armeabi-v7a armeabi
Compatible device ABI: armeabi-v7a
Using gdb setup init: ./libs/armeabi-v7a/gdb.setup
Using toolchain prefix: /cygdrive/e/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-
Using app out directory: ./obj/local/armeabi-v7a
Found debuggable flag: true
Found device gdbserver: /data/data/myndkpackage/lib/gdbserver
Found data directory: '/data/data/myndkpackage'
Found first launchable activity: myndkpackage.MainActivity
Launching activity: myndkpackage/myndkpackage.MainActivity
COMMAND: adb_cmd shell am start -D -n myndkpackage/myndkpackage.MainActivity
Starting: Intent { cmp=myndkpackage/.MainActivity }
COMMAND: adb_cmd shell sleep 2
Found running PID: 2787
Killing existing debugging session
COMMAND: adb_cmd shell kill -9 2753
Launched gdbserver succesfully.
Setup network redirection
COMMAND: adb_cmd shell run-as myndkpackage lib/gdbserver +debug-socket --attach 2787
COMMAND: adb_cmd forward tcp:5039 localfilesystem:/data/data/myndkpackage/debug-socket
Attached; pid = 2787
Listening on Unix socket debug-socket
COMMAND: adb_cmd pull /system/bin/app_process obj/local/armeabi-v7a/app_process
599 KB/s (9588 bytes in 0.015s)
Pulled app_process from device/emulator.
COMMAND: adb_cmd pull /system/bin/linker obj/local/armeabi-v7a/linker
658 KB/s (63244 bytes in 0.093s)
Pulled linker from device/emulator.
COMMAND: adb_cmd pull /system/lib/libc.so obj/local/armeabi-v7a/libc.so
744 KB/s (297608 bytes in 0.390s)
Pulled libc.so from device/emulator.
Setup JDB connection
COMMAND: adb_cmd forward tcp:65534 jdwp:2787
java.io.IOException: handshake failed - connection prematurally closed
at com.sun.tools.jdi.SocketTransportService.handshake(SocketTransportService.java:136)
at com.sun.tools.jdi.SocketTransportService.attach(SocketTransportService.java:232)
at com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:116)
at com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:90)
at com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:519)
at com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:328)
at com.sun.tools.example.debug.tty.Env.init(Env.java:63)
at com.sun.tools.example.debug.tty.TTY.main(TTY.java:1066)
Fatal error:
Unable to attach to target VM.
/cygdrive/e/android-ndk-r9/ndk-gdb: line 742: 4636 Segmentation fault $GDBCLIENT -x native_path $GDBSETUP
Blockquote
Ok,
From what I understand, its a problem in the new r9 release, specifically in the file named
android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-gdb
This executable gives the segmentation fault.
So it looks that in the distro it has not been generated correctly from the start, from the android devs themselves who uploaded it on the main android site.
I tried and re-downloaded the r9 distribution and re-installed, yet the same thing happens so it was not something accidental eg a bad unzip.
I tried the older r8e same file and it does not give the segmentation fault, it works ok.
So, I did something to get a proof of concept of what I say and took the previous version file (from r8e) and overwrite the new r9 file, then tried again to run the failing ndk-dbg and..
..IT WORKS..
Now I have a new r9 NDK but with one file from the r8e, the old arm-linux-androideabi-gdb.exe and everything works just fine!
So I guess the android devs have to re-do the compilation of the
-> android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-gdb.exe
tool, properly this time.
At least I hope someone will find this useful and avoid the frustration that I had all this time.
Christos
This is the bug that was opened on the Android NDK. A work-around is to use the arm-linux-androideabi-gdb.exe from Android NDK r8e (as described in Christos' answer), or to download a fixed file from http://code.google.com/p/mingw-and-ndk/downloads/detail?name=arm-linux-androideabi-gdb.exe.
Just for the record, the problem with gdb appears to be fixed in r9b of the NDK.
https://developer.android.com/tools/sdk/ndk/index.html
Fixed a problem with Windows 32-bit *-gdb.exe executables failing to
launch. (Issue 58975)
I've installed the latest Node.js for Windows x64 (0.8.19). When I run it, with or without a script file argument it just exits without an error message.
Things I've tried:
I ran node.exe under JetBrains Webstorm, this reported an exit code of -1073740791
I compiled the source code for 0.8.19 using VS2010, this has the same problem in release but in debug it reports the error: Run-Time Check Failure #2 - Stack around the variable 'buf' was corrupted. Continuing from this in debug allows the program to start up.
I installed node.js on my PC at home which is also Win 7 x64 and that worked fine.
Have others had the same problem?