How do I find out which thread is the owner of my Event handle in windbg:
I'm running
!handle 00003aec f
and get
Handle 00003aec
Type Event
Attributes 0
GrantedAccess 0x1f0003:
Delete,ReadControl,WriteDac,WriteOwner,Synch
QueryState,ModifyState
HandleCount 2
PointerCount 4
Name <none>
No object specific information available
back, and as there is no Name I haven't figured out how to get the owner out to prove which thread my thread is waiting on
[Edit] I must work against a dump as the original process needs to be restarted on the users machine, so can't debug a live session
The best discussion on the subject I've found so far is on this blog, but unfortunately we end up using different lock methods (I end up using WaitForMultipleObjectsEx and the description is for WaitForSingleObject), and he seems to have access to a live process
the stacktrace of my thread (the one that is blocked on something and where I'm looking for the current owner) is:
0:045> k9
ChildEBP RetAddr
1130e050 7c90e9ab ntdll!KiFastSystemCallRet
1130e054 7c8094e2 ntdll!ZwWaitForMultipleObjects+0xc
1130e0f0 79ed98fd kernel32!WaitForMultipleObjectsEx+0x12c
1130e158 79ed9889 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
1130e178 79ed9808 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
1130e1fc 79ed96c4 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
1130e24c 79ed9a62 mscorwks!Thread::DoAppropriateWait+0x40
1130e2a8 79e78944 mscorwks!CLREvent::WaitEx+0xf7
1130e2bc 7a162d84 mscorwks!CLREvent::Wait+0x17
1130e33c 7a02fd94 mscorwks!CRWLock::RWWaitForSingleObject+0x6d
1130e364 79ebd3af mscorwks!CRWLock::StaticAcquireWriterLock+0x12e
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Looking at the callstack it appears that the stack in question is using a ReaderWriterLock locking mechanism.
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
Change to thread 9 and using sos.dll run !dso to dump out the managed ReaderWriterLock object. Then run !do on that the ReaderWriterLock object. I believe that there is an owning thread field that you can query. I will test it and see.
The old school way to determine this is to run ~*e !clrstack and examine all of the managed threads that are waiting on a readerwriter lock and then see if you can find the thread that has entered the same function but passed through the lock (ie. different offset)
Thanks,
Aaron
Note: Not sure if there is a way to link posts but this one is very similar to
How do I find the lockholder (reader) of my ReaderWriterLock in windbg
Use the !htrace command to get the thread ID. You must first, possibly at the start of the program, enable the collection of traces with !htrace -enable.
0:001> !htrace 00003aec
--------------------------------------
Handle = 0x00003aec - OPEN
Thread ID = 0x00000b48, Process ID = 0x000011e8
...
The above output is fictional, it will be different for your system. But it will give you the piece of information you need - the thread ID (0x00000b48 in my example).
I must work against a dump as the
original process needs to be restarted
on the users machine, so can't debug a
live session.
I am not 100% sure but I think this will work:
Attach to the process and run !htrace -enable
Detach from the process with qd. The executable will continue.
You can now take a dump file and use the above command - I think you will have the described results.
You can dig that out of a kernel dump.
Now, as far as kernel debugging goes, livekd from sysinternals should be sufficient but unfortunately it is only usable on a running system.
There's also a kernel mode memory acquisition tool which might be of use to take a dump with (in windbg's stead) for later inspection.
Otherwise, enabling handle tracing (!htrace -enable) and (if code unique to particular thread), the handle ownership could be concluded from a stack trace.
Here's the definitive answer I found. Never tried myself. You'll need live debugging to determine the owner though. But it's pretty quick.
http://weblogs.thinktecture.com/ingo/2006/08/who-is-blocking-that-mutex---fun-with-windbg-cdb-and-kd.html
Related
I'm trying to run this (script.exs):
System.cmd("zsh", ["-c" "com.spotify.Client"])
IO.puts("done.")
Spotify opens, but "done." never shows up on the screen. I also tried:
System.cmd("zsh", ["-c" "nohup com.spotify.Client &"])
IO.puts("done.")
My script only halts when I close the spotify window. Is it possible to run commands without waiting for it to end?
One should not spawn system tasks in a blind hope they would work properly. If the system task crashes, some actions should be taken in the calling OTP process, otherwise sooner or later it’ll crash in production and nobody would know what had happened and why.
There are many possible scenarios, I would go with Task.start_link/1 (assuming the calling process traps exits,) or with Task.async/1 accompanied by an explicit Task.await/1 somewhere in the supervision tree.
If despite everything explained above you don’t care about robustness, use Kernel.spawn/1 like below
pid = spawn(System, :cmd, ~w|zsh -c com.spotify.Client|)
# Process.monitor(pid) # yet give it a chance to handle errors
IO.puts("done.")
In MINIX 3.2.1, I want to create a new system call in VFS server which will be given a filename as a parameter and will print this certain file's inode number.
So in order to retrieve the inode of the file by its name I want to use the default system call:
int stat(char *name,struct stat *buffer)
http://minix1.woodhull.com/manpages/man2/stat.2.html
in the body of my new system call handler which is
int mycall_1(void);
inside `/usr/src/servers/vfs/misc.c
But when I test the new system call, at the point where the stat system call should be invoked, it actually won't and instead it's printing the message:
sys_call: ipc mask denied SENDREC from 1 to 1
After some research, I found that this possibly happens because the VFS server tries to send a message to itself, as stat is actually implemented inside VFS server, and so ipc mask denied this sendrec() call. So I have to edit some configuration file in order to give the right permission for this communication to happen.
But I'm not sure if what I have understood is right and also do not know which file should Ι edit to give the appropriate permissions. So, if someone could enlighten me on this issue, I would be grateful.
Thanks in advance.
You understood it correctly. But the solution is not to continue "fixing the permissions" which are here just to prevent to shot yourself in the foot: it would only allow the system to more badly brocken.
Rather, you need to perform the steps that VFS do when it services a STAT request, starting after it cracked the message.
I need to log trace events during boot so I configure an AutoLogger with all the required providers. But when my service/process starts I want to switch to real-time mode so that the file doesn't explode.
I'm using TraceEvent and I can't figure out how to do this move correctly and atomically.
The first thing I tried:
const int timeToWait = 5000;
using (var tes = new TraceEventSession("TEMPSESSIONNAME", #"c:\temp\TEMPSESSIONNAME.etl") { StopOnDispose = false })
{
tes.EnableProvider(ProviderExtensions.ProviderName<MicrosoftWindowsKernelProcess>());
Thread.Sleep(timeToWait);
}
using (var tes = new TraceEventSession("TEMPSESSIONNAME", TraceEventSessionOptions.Attach))
{
Thread.Sleep(timeToWait);
tes.SetFileName(null);
Thread.Sleep(timeToWait);
Console.WriteLine("Done");
}
Here I wanted to make that I can transfer the session to real-time mode. But instead, the file I got contained events from a 15s period instead of just 10s.
The same happens if I use new TraceEventSession("TEMPSESSIONNAME", #"c:\temp\TEMPSESSIONNAME.etl", TraceEventSessionOptions.Create) instead.
It seems that the following will cause the file to stop being written to:
using (var tes = new TraceEventSession("TEMPSESSIONNAME"))
{
tes.EnableProvider(ProviderExtensions.ProviderName<MicrosoftWindowsKernelProcess>());
Thread.Sleep(timeToWait);
}
But here I must reenable all the providers and according to the documentation "if the session already existed it is closed and reopened (thus orphans are cleaned up on next use)". I don't understand the last part about orphans. Obviously some events might occur in the time between closing, opening and subscribing on the events. Does this mean I will lose these events or will I get the later?
I also found the following in the documentation of the library:
In real time mode, events are buffered and there is at least a second or so delay (typically 3 sec) between the firing of the event and the reception by the session (to allow events to be delivered in efficient clumps of many events)
Does this make the above code alright (well, unless the improbable happens and for some reason my thread is delayed for more than a second between creating the real-time session and starting processing the events)?
I could close the session and create a new different one but then I think I'd miss some events. Or I could open a new session and then close the file-based one but then I might get duplicate events.
I couldn't find online any examples of moving from a file-based trace to a real-time trace.
I managed to contact the author of TraceEvent and this is the answer I got:
Re the exception of the 'auto-closing and restarting' feature, it is really questions about the OS (TraceEvent simply calls the underlying OS API). Just FYI, the deal about orphans is that it is EASY for your process to exit but leave a session going. This MAY be what you want, but often it is not, and so to make the common case 'just work' if you do Create (which is the default), it will close a session if it already existed (since you asked for a new one).
Experimentation of course is the touchstone of 'truth' but I would frankly expecting unusual combinations to just work is generally NOT true.
My recommendation is to keep it simple. You need to open a new session and close the original one. Yes, you will end up with duplicates, but you CAN filter them out (after all they are IDENTICAL timestamps).
The other possibility is use SetFileName in its intended way (from one file to another). This certainly solves your problem of file size growth, and often is a good way to deal with other scenarios (after all you can start up you processing and start deleting files even as new files are being generated).
I`m playing around with CLR Memory Diagnostics tool in order to analyze memory dumps.
Opening a dump using WinDBG, I am able to use .time command to get the debug session time (when dump was captured).
Does anybody knows the ClrMD API to get the date?
I've found the following way to solve this task, however it restricts us to the DbgEng usage only.
Open dump file and specify DbgEng (so IDebugClient will be used)
DataTarget.LoadCrashDump(pathToMemoryDumpFile, CrashDumpReader.DbgEng));
Use the IDebugControl2 COM interface to get target time (ensure that you perform that on the same thread that started the session):
uint secondsSinceUnix;
var dbgCtrl2 = (IDebugControl2)sessionContext.DataTarget.DebuggerInterface;
dbgCtrl2.GetCurrentTimeDate(out secondsSinceUnix);
Convert secondsSinceUnix to DateTime using the approach described here.
As output you will get UTC date time of the memory dump creation (or attaching time).
It worked well for me :)
We have an virtual audio device driver similar to Sound flower. This virtual device will be listed in sound system preferences. Whenever our device gets selected in system preferences, it prevents idle sleep. If we switch the selection to default output device, everything works as expected.
If we execute 'pmset -g assertions' command in Terminal, it gives below output
Assertion status system-wide:
ChargeInhibit 0
PreventUserIdleDisplaySleep 0
PreventUserIdleSystemSleep 1
NoRealPowerSources_debug 0
CPUBoundAssertion 0
EnableIdleSleep 1
PreventSystemSleep 0
DisableInflow 0
DisableLowPowerBatteryWarnings 0
ExternalMedia 0
Listed by owning process:
pid 115: [0x0000012c00000073] PreventUserIdleSystemSleep named: MY_DRIVER_IDENTIFER.noidlesleep"
Could any one suggest me some pointers to resolve this issue.
I think this governed by the flag kIOPMPreventIdleSleep, which resides in the capabilityFlags field of the IOPMPowerState struct.
To participate in power management decisions, you'll need to add your device driver to the power management plane, typically in your overridden IOService::start(provider) method:
PMinit();
provider->joinPMtree(this);
registerPowerDriver(this, powerStates, numPowerStates);
where powerStates and numPowerStates specifies an array of power states you want your device to be able to be in. You'll probably not want more than 2 for a virtual device, and maybe you even only need one. I suspect a superclass of your class is setting states that are inhibiting sleep. Once you've registered for power management, your driver will be expected to handle the power management methods such as IOService::setPowerState().
Depending on how you want your device to behave, you might want to create 2 power states, one "live" when playing back or capturing sound (and inhibiting sleep) and the other "idle" when the device isn't doing anything, and allowing sleep.
The power management topic is a bit too big to cover entirely in a StackOverflow answer, so I suggest you read the docs on the stuff I've mentioned above and try clearing the relevant flag in your power state(s).
Hope that helps.