I am using Flutter to develop a Windows program, Need to disable input method, Find the relevant documentation, you can use the ImmDisableIME(0) method to disable the input method. But when I try to call this method, An exception was reported when running the project.
main.cpp
win32_window.cpp
How to properly disable the input method?
An exception was reported when running the project
No. An exception was not reported when running the project. Rather, your program never ran to begin with because it had a compiler error.
Because you are passing -1 to a function expecting an unsigned integer (DWORD), the compiler is warning you (C4245). And your build environment treats warnings as errors (C2220).
To invoke it with -1 such that it disables for all threads in the current process, then invoke it as follows with a cast. It's as easy as that.
DWORD dwParam = (DWORD)(-1);
ImmDisableIME(dwParam);
Related
I'm building AOSP from source and have created a small C++ program that prints some messages to logcat when started. Now I wanted to debug the program according to https://source.android.com/devices/tech/debug/gdb
In the reference you're encouraged to use lldb in favor of gdb and there is also a short section on using vs code as debugger.
However, I cannot find the mentioned script lldbclient anywhere in my source nor in Android Code Search, only gdbclient.py seems to be present.
Q1: Where can I find lldbclient script?
When running the gdbclient.py script the option --setup-forwarding vscode seems to be ignored and gdb is always started.
Q2: If there isn't a lldbclient script, what options do I have to pass to gdbclient.py to enable debugging with lldb and vs code?
What did I do so far?
gdbclient.py -r /data/mysample_bin --setup-forwarding vscode
Starts my native program with attached gdb and allows me to step through my program.
Though I do not know how to code python, I was able to track down a call sequence in the script to method generate_setup_script, which is called with parameter debugger=gdb. Therefore no lldb configuration for vs code is created. Passing --no-gdb or --lldb to the script doesn't change this behavior.
Q1: You can find lldbclient.py script in the repository https://android.googlesource.com/platform/development, branch android-s-beta-2 (or another android-s branch).
Q2: Android also provides some tutorial debugging with Vscode: https://source.android.com/devices/tech/debug/gdb#vscode.
While I was compiling this project https://github.com/namazso/hdd_serial_spoofer
I got the error message above ,how can I solve this ?
I'm using vs 2017 and wdk 10 .
(Must compile in release ,debug mode is not supported .There is no DriverEntry function in this project ,the EntryPoint(void* ntoskrn, void* image, void* alloc) function in hwid.cpp is the real entry point .)
I did a lot of research but still failed to get it work .I'm a noob in kernel mode driver development .
The project uses (an apparently ignored) option
<EntryPointSymbol> to define EntryPoint as the entry.
This is documented here, but current documentation appears to mean this is really only for .exe and .dll projects.
The form of the mesage called from the Windows driver system
NTSTATUS DriverInitialize(
_DRIVER_OBJECT *DriverObject,
PUNICODE_STRING RegistryPath
)
Is incompatible with the EntryPoint in the project
EntryPoint(void* ntoskrn, void* image, void* alloc)
This is not so bad, as none of the parameters which are called for EntryPoint are used.
So the simplest implementation would be
extern "C"
{
DRIVER_INITIALIZE DriverEntry;
_Use_decl_annotations_
NTSTATUS
DriverEntry(
struct _DRIVER_OBJECT *DriverObject,
PUNICODE_STRING RegistryPath
)
{
EntryPoint(NULL, NULL, NULL);
return STATUS_SUCCESS;
}
}
Kernel development is not for the faint hearted, and running invalid kernel code on your computer could make it difficult to boot, or in extream cases damage the computer. I did not review any of the code in the project for correctness.
Please run the code in a virtual machine (vmware, virtualbox, hyper-v) to limit the damage it could do
This is not a normal driver, the kind that WDF directly supports. It is a "driverless driver", it uses an undocumented hack that is appealing to the kind of programmers that write rootkits for fun and profit. The DriverEntry() function is not actually the entrypoint for a driver, it is callback. Much like the WinMain() function is not actually the entrypoint for a native Win32 program. The EntryPoint() function in the project's source code is the replacement for the native driver entrypoint. Beware that the project appears to have rootkitty-like behavior, designed to fool a simplistic copy-protection scheme that checks a drive serial number.
The GsDriverEntry() function is the real entrypoint in a normal KMDF driver. It performs essential initialization to support the /GS compiler option, designed to detect buffer overflow. After that's done it calls DriverEntry(). The project replaces this entrypoint with EntryPoint().
This project was written with an old version of the Visual Studio project template. Several changes are necessary to get it to build properly:
C/C++ > Code Generation > Security Check. Must be "Disable security check (/GS-)", the original project file got this right.
Same property page > Control Flow Guard. Must be set to "No" to prevent a linker error. This option adds additional security checks that cannot work and must be disabled.
C/C++ > General > SDL checks. Use the dropdown arrow to override to "inherit from parent" so the option appears blank. More security checks that needs to be disabled, suppresses a warning that sdl- is incompatible with /gs-.
Same property page > Warning level. Override to "Level3 (/W3)", suppresses warnings about function arguments not being used.
Linker > Input > Additional Dependencies. Click the dropdown arrow > Edit. Untick the "Inherit from parent" checkbox and change to $(DDK_LIB_PATH)ntoskrnl.lib. Note the $(KernelBufferOverflowLib) entry in the Inherited values listbox, resolves to bufferoverflowfastfailk.lib, that is the one that contains GsDriverEntry() and produced the linker error.
Linker > Advanced > Entry Point. Must be "EntryPoint", the original project template got that right.
After this it builds clean. I did not test the resulting hwid.sys, looks a bit too evil to expose my machine to it.
Don't use .cpp source files to write your driver. Change them to .c and it should work. That was the case for me.
I know it looks trivial, or unlikely but remember Windows Kernel code is C code and Visual Studio makes various assumptions given the file extension of your source files.
There are several causes that generate the problem. In my case, a try/except in the code, which compiles on x64, but doesn't compile on x86.
Linker Tools Error LNK2019
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2019?view=msvc-170
I built a (customized) 1.8 HotSpot VM in Netbeans 7.2 using GDB 7.4 which works for executing Java programs. I want to debug a SIGSEGV that the program produces by calling a native function called by JNI that corrupts an object header.
However, I have some problems debugging the HotSpot VM: I have several breakpoints before the call to the main function in java.c. Sometimes, they trigger and sometimes the main function executes without all the breakpoints halting before. The most far I can get is
/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
After that, a step-in runs through the whole Java program, eventually triggering the SIGSEGV. The call is leading to the JNI API so I included the "hotspot/src/share/vm/prims" directory to the source dirs in the debug section. However, I could not see any effect. Does anybody have an idea how I can step into the C++ method calling the Java main method?
When the SIGSEGV causes the Netbeans debug view to stop, the call stack shows the expected call stack. However, instead of the C++ code it just shows assembler code while displaying the names of the C++ classes. The initial caller is "?? ()". Is there some way to see the C++ code or do I have to manually map the assembler code to the C++ code? I read a great article by Volker Simonis where he describes that such unknown frames relate to generated code. However, I'm still puzzled that the consecutive caller frames show class and method names. Is it a problem with source lookup or simply relates to the first unknown frame?
Did you compile hotspot in debug mode, i. e. make all_debug? If hotspot is optimised than code may be run in different order than it's in source file, and some symbols can be stripped out, preventing debugger to give you meaningful info, or setting a breakpoint.
Compilation of my code in both modes debug and release is successful. Debug mode execute and works fine, but when i execute release mode, it says "the application was unable to start correctly 0x80000003".
What is this error and why debug mode works fine but not release.
DLLs for debug and release are present in the same directory name "bin". "lib" for both modes also placed in the same directory.
I tried to solve it many ways but not succeeded ? Guide me how to solve this issue? Thanks.
why debug mode works fine but not release
Thre can be many reasons why one build works while another doesn't. The shape and size of data structures can be different because of #ifdef or because the compiler emits different code, the code being executed can be different - again because of constructs like #ifdef or because of the code the compiler is emitting.
That can matter when you've got code with a bug in it. Let's say you've got a bug that miscalculates the length of an array (or the size of a structure or whatever). You do some pointer arithmetic and write some data into memory using that pointer - only you're writing to the wrong place. Whether that mistake breaks your program may depend on what was in the memory you overwrote.
If you're lucky your program crashes almost immediately because what you overwrote was important to some code executed immediately after your bug. If you're only a little bit lucky your program crashes some time later in a completely different part of your program because what you overwrote was important to code far away from your bug. If you're really unlucky your program doesn't crash at all until several years later when a completely unrelated change moves things around in memory so now what you are overwriting suddenly is important.
There are lots of other possible causes of what are sometimes called Heisenbugs
What is this error
One place to look for errors like 0x80000003 is the file WinError.h which you'll find in the SDK you are using (either the one that came with Visual Studio 2010 or one you installed later). Look in WinError.h and you'll find that that E_INVALIDARG is defined to be _HRESULT_TYPEDEF_(0x80000003L).
That doesn't necessarily help though because we we don't know enough about what is returning that error or why it is returning that error or even that your 0x80000003 is in fact an E_INVALIDARG - it could be some other error with the same value, or some piece of code mis-using E_INVALIDARG or something else.
Another possibility is that 0x80000003 is a hard-coded breakpoint exception being thrown - most likely because your program has got to one of those "this should never happen" places where the only thing that makes sense is to throw an exception and crash. If you look in NtStatus.h (in the same place as you found WinError.h) you'll find that STATUS_BREAKPOINT is defined to be ((NTSTATUS)0x80000003L)
how to solve this issue
The trick is to figure what is causing the 0x800000003 (and where in your code it is happening) so you can narrow down why it is happening. Most likely it's an exception but why jump to conclusions?
You can run a release build inside the debugger just as you would run a debug build - that is, build the code using the Release target and then press F5 or Debug | Start Debugging. Look in the Output Window and you may see some information that will help you interpret the error.
You can also use the Debug | Exceptions menu to add a new Win32 Exception with the value 80000003 and set that up to break when thrown rather than to break when unhandled. That way you should stop in the debugger when that exception is thrown (if it is in fact thrown).
Of course it could be that even running your program within a debugger is enough to change things so your problem doesn't occur.
I have a strange problem, I hope you can help me.
I write a program in C++ Builder 2009, when I run the program without debugger I see an Exception raised. bun in debugger never exception raised and I cant find the exception point.
And Also I enable the CodeGaurd in C++ for Finding the problem but the Exception never raised, If I disable codeGuard the exception will be here again.
I use OpenCV and some Delphi units in the program.
And when I compile it I see more than 2 millions of code line compiled.
Thanks in advance for your attentoin.
A few things too look at:
in the IDE options, make sure you are not ignoring some exceptions
debug builds MAY have memory variables set to NULL on run, release builds will not. Make sure you are running the same build (Debug) in both the IDE and without.
Ignore the line count that is displayed, its all those .hpp files that holds the vcl headers.