I am getting an error as follows on running my application :
LTTng-UST: Error (-17) while registering tracepoint probe. Duplicate
registration of tracepoint probes having the same name is not allowed.
Based on error, looks like multiple components are trying to register with same tracepoint probes. I am trying to find which are those components. Is there any way to see who all are registering tracepoint probes?
Thanks,
Kailas
Related
I'd like to get event in kernel on each new process that starts (fork+execve or posix_spawn), and be able to prevent this operations.
The first option would be using Mac framework named mpo_vnode_check_exec by Hooking to this method with function that return 0 when access is granted or check deferred to next hook.. non zero returned value means access is refused right away.
Unfortunately, this framework is unsupported by apple, and I wish to use a stable alternative like kauth fileop scope with KAUTH_FILEOP_EXEC flag.
However, this framework is for detection only and lacks prevention capabilities..
Perhaps there's a way to prevent the process from running when I get relevant kauth callback on process creation, or halt the process from running until I decide whether it should run or not (and enforce the verdict in another thread).
thanks
However, this framework is for detection only and lacks prevention capabilities..
Correct, if you're only focussing on the File scope.
Register with the Vnode scope and your callback returns whether or not access is allowed.
kauth_listen_scope(KAUTH_SCOPE_VNODE, &myCallback, NULL);
Finally, note that this scope is very noisy, as every type of access to every resource is reported.
I receive letting_statedump events when I enable these events and start the tracing. I noticed that I receive this only once for the life of the trace session. How would I initiate the generation of statedump events without stopping the trace and restarting?
As far as I know, there is no way at the moment to trigger a statedump manually.
However I would ask, why would you need to do so? The goal of the statedump is for trace viewers or analysers to be able to have an idea of the initial state of the system. Afterwards, they can use the actual trace events to update their state trackers.
If you do not wish to write your own state tracker, another option that may help are the event contexts. If you enable a context like pid or procname, that information will be dumped as part of every trace event. This can be used to get up-to-date state information more easily. You can use
lttng add-context --help
to list the available contexts.
I've written a TopShelf service and I'd like to do some validation when the service starts. If the service is horribly misconfigured, I want to give a nice error message and gracefully stop.
To do that, I've put my validation code into BeforeStartingService. When I run my service from the console, this works great. However, when I run as a service, my logging code doesn't write anything.
Is this an appropriate use case for BeforeStartingService? Is there some trick that I need to write to the log from it? I'm using Log4Net. I've tried disabling log4net entirely and just using the default trace logger. I've tried getting the logger through TopShelf with HostLogger.Get, as well as directly from Log4Net with LogManager.GetLogger.
Thanks in advance.
I have a windows service. I also develop a driver for a device.
I want my service to start only when the device is plugged in.
I thought that maybe I can somehow start the service from the driver, but after googling it, I understood that it is forbidden.
Is there any other way to start a service or an application from system event.
The StartService Function documentation discusses conditions for starting a service, including discussions about when it cannot be used and how to check for that condition. It specifically says that:
When a driver service is started, the StartService function does not
return until the device driver has finished initializing.
So, you'd have to complete device initialization before issuing the StartService, but that should be possible?
What I am going to do is to register my application as a task in Task Scheduler, and set the trigger to event in the event log.
Then in my driver I will raise this specific event.
This way I can run an application from the driver.
we're shipping a shell extension dll (registered with regsvr32).
is there an easy way to get debug output from this dll from another application (so we can send these traces home when something is broken)?
any ideas? what's the easiest way to get logdata from the dll to another process?
If it's a shell extension DLL, then doesn't it run as the logged-in user, and can't it therefore write to a log file in some suitable directory on disk? If so why then would you want it to write to another process?
You can use Event Tracing for Windows (ETW) to trace your extension DLL execution. ETW has almost no overhead when no listener is active, so in normal conditions your DLL will incur no perf penalty; at the same time it allows for detailed output at various levels of details.
The way ETW works is when the APIs are called, they check if there is a listener subscribed to the traces from particular publisher and if no, nothing is generated. If there is a listener, only the traces to which the listener is subscribed are written to a memory-mapped file. Thus, only as much traces data is generated as requested.
ETW listeners can be activated at any time and the publisher does not have to be restarted. Also, ETW is not flavor bound and can be used in both debug and retail. Thus, if a customer of yours has a problem, you have to only send them the listener with instructions on how to run it and collect the info; you don't have to sent them an instrumented binary version. You can either write your own app that acts as a listener, or you can use the standard tracelog.exe and tracefmt.exe tools to get the traces written to a file.
To generate the necessary ETW code in your DLL, you can use the WPP preprocesor instead of directly using the ETW APIs.
Note: While all the links I post here are to the Windows Driver Kit documentation, ETW and WPP can be (and are heavily) used for regular user mode programs.