I wish to hook a MTP method bool MtpDevice::openSession() in MtpDevice.cpp, this method should be running in android.process.media.
When I try to hook package name android.process.media, it do not being hit at all.(Maybe this process name is not a package name at all).
Since this process is launched by system bootup, I do not know how can I hook it.
The package name of android.process.media should be com.android.providers.media. refer to this file.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.providers.media"
android:sharedUserId="android.media"
android:sharedUserLabel="#string/uid_label"
android:versionCode="1023">
Related
In my code I imported a package "github.com/Microsoft/go-winio"
And when ever I try to call winio.DialPipe It says DialPipe not declared by winio
I want to access named pipe in windows
I am using MacOs(M1) to code.
I tried reading the microsoft implementation and there I can find they have delared DialPipe in a file named pipe.go. What should I do in this situation??
We have installshield 2016 and inside this we are running installer script. That script is call through custom action.
So we are written following commnad to register "mydll.dll" as below mentioned command,
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe /codebase mydll.dll
The above command works perfectly fine when run manually through command prompt with administrative access.But fails through installer created using installshield script custom action.
To run command we use LaunchApplicationAndWait() and LaunchApplication() functions as
strcmd = "path to cmd.exe" + "cmd.exe"
strcmdopt = "path to regasm.exe" + "regasm.exe " + /codebase + path and name of dll
ret = LaunchApplication(strcmd, strcmdopt, windir, sw_normal, infinite, LAAW_OPTION_WAIT | LAAW_OPTION_SHELLEXECUTE)
similarly
ret = LaunchApplicationAndWait(strcmd ,strcmdopt,LAAW_OPTION_WAIT | LAAW_OPTION_HIDDEN)
My Question is why both command not work when run through installshield custom action scripts
Is the dll distributed with the installation? if so, is the file present in the installdir (or wherever) when the script is called? Maybe add some msg box for debug purposes to see if this condition is met.
Im using deferred custom action to register .dll via regasm and it works just fine.
You shouldn't be calling Regasm during the install. You should put the DLL as a key file in it's own component and set the COM Interop = True attribute. This will cause InstallShield to perform a regasm /regfile during the build and take the output and dynamically author it into the Registry table. During the install, MSI will simply copy the file and apply the registry entries and your done.
Note: Per MSDN doco custom functions are not called during regasm /regfile so if you are doing any wierd self registration inside your class you'll need to author that into the installer.
Normally, if I use rmmod to remove a kernel module, the function specified by module_exit is run. Is there some way to rmmod without having this function invoked?
In case you're curious, the reason is that I have written and insmod'ed a module whose exit method is buggy and I'd prefer not to reboot the remote machine manually when it causes the kernel to hang.
I have looked at man rmmod, but it does not seem to have such an option.
It is not possible to avoid unloading your module when rmmod is executed because there is some cleanup activity required when your module unloads, which if not done, you 'll not be able to reload your module again by executing insmod, as it will again call module_init() where you would have functions to registered (alloc_chrdev_region() or register_chrdev()) your driver. Re-registering it without un-registering it will result in a failure to load your module.
I'm not sure if this does what you are asking, but the next time you recompile the kernel you can enable the MODULE_FORCE_UNLOAD option and try rmmod -f
https://lwn.net/Articles/15571/
I am currently trying to debug my Crash-Handler, it is an external executable that gets called when my program finds an unhandled structured exception. I recompiled the crash-handler executable, and when I tested, I got a message: "Program too big to fit in memory".
After digging around for a bit, I found that this was being caused by the CreateProcess call within my unhandled exception filter. I found this post that says that this error message indicates that the executable is corrupted, however if I invoke the CrashHandler.exe from the command line, I get no such error.
Other Information:
I have tried rebuilding my
application and the crash-handler
multiple times in both debug and
release mode.
I have tried giving the running thread 2 orders of magnitude more stack space.
I tested the same CrashHandler.exe in another application that was already using it, and there were no problems.
I tried using a previous version of the exe that worked before, but with the same result.
Restarting the system.
My Call to CreateProcess:
//Fire off the Handler
//HandlerArgs = "CrashHandler.exe arg1 arg2 arg3 etc..."
if(CreateProcess(NULL, HandlerArgs, NULL, NULL, TRUE, CREATE_PRESERVE_CODE_AUTHZ_LEVEL | CREATE_SUSPENDED,
NULL, NULL, &StartupInfo, &NewProcessHandle))
Turns out that one of my post-build hooks was copying over the exe from The source control repository, and the file I had in the source control repository was actually the pdb. While testing I was copying directly to my running folder, and then the hook would copy the "corrupted" exe over again.
The Custom Action is configured as follows:
Custom Action Name: MyCustomAction
VBScript Filename: <PathVar01>\MyFolder\MyVBSfile.vbs
ScriptFunction: MyFunction
Return Processing: Synchronous (Check exit code)
In-Script Execution: Immediate Execution
It is being executed via the following InstallScript code:
result = MsiDoAction(ISMSI_HANDLE,"MyCustomAction");
When the setup reaches that line in InstallScript, the installer shows an error alert, stating:
"Error 1720.There is a problem with
this Windows Installer package. A
script required for this install to
complete could not be run. Contact
your support personnel or package
vendor."
The result code returned by MsiDoAction is that of '1603', which, according to winerror.h, is:
//
// MessageId: ERROR_INSTALL_FAILURE
//
// MessageText:
//
// Fatal error during installation.
//
#define ERROR_INSTALL_FAILURE 1603L
Why is this happening? I was starting to doubt that the file was included properly. Yet, I am pointing to the correct file, and I've tried including the VBS via the InstallShield Support Files, thinking this would ensure the file was present with the setup, but same result.
Running the setup with logging enabled revealed the problem:
Action 13:29:19: MyCustomAction.
Action start 13:29:19: MyCustomAction.
Error 1720.There is a problem with
this Windows Installer package. A
script required for this install to
complete could not be run. Contact
your support personnel or package
vendor. Custom action MyCustomAction
script error -2146827278, Microsoft
VBScript compilation error: Expected
identifier Line 163, Column 37,
blnExample,)
To run a setup with logging enabled:
"C:\SetupFolder\setup.exe" /V"/l*v
c:\Install.log"
This forum thread was helpful.