I have the problem that my solution build on Callback File System at times stops. The last function executet is CbFsSetFileAttributes and this returns with no errors. But after this no more callback functions are called and the system stops completely. The only way out is the power switch.

1) Is this a normally behaviour for a deadlock or is there another problem.

2) I had the understanding that a call to SetUseSystemCache(TRUE) would prevent deadlock 100%. But after reading the thread http://www.eldos.com/forum/read.php?FID=13&TID=958&MID=5175&phrase_id=286132#message5175 I am confused - special

Quote

I am sorry but this is not a meaningful report.

There's a limited set of operations that are allowed in callbacks. Doing many things can cause a deadlock. So you must be *very* careful about what you are doing in callbacks. Ideally, in callbacks you should only read/write local information from/to memory, leaving network and disk operations for other thread, which works in background.

Sincerely yours,
Eugene Mayevski

make me wonder, as this stats that the mapper sample can deadlock.

3) The code part in CbFsSetFileAttributes

Code

if(CreationTime != NULL)
{
CreationPtr = CreationTime;
}

if(LastAccessTime != NULL)
{
LastAccessPtr = LastAccessTime;
}

if(LastWriteTime != NULL)
{
LastWritePtr = LastWriteTime;
}

does not make sense for me. Would the result not be the same if e.g. CreationTime was used directly ??.

Søren Kristensen wrote:
1) Is this a normally behaviour for a deadlock or is there another problem.

I don't know. It's more preferable if you give us a sample that causes the problem. Or at least specify what do you do in the CbFsSetFileAttributes callback.
And could you perform the following:
1. Install the checked (i.e. debug) version of the driver from the latest build.
2. Set in the system "Startup and Recovery" settings to generate a "kernel memory" crash dump (for details see the CallbackFS documentation).
3. Run the attached to this message program (it's called BANG! and was taken from osronline.com).
4. Run your CallbackFS implementation. And when the deadlock occurs then use BANG! to generate a BSOD.
5. After the computer reboots, send me the crash dump. It will be quite big (for about 70Mb).
Thanks.

Unfortunately some operations in the callbacks are not possible due to high cohesion of CallbackFS with the system. If it's necessary to perform something that causes a deadlock (for example writing to the debug console from the read or write callbacks or showing GUI-windows) then do it asynchronously from other threads.

Quote

Søren Kristensen wrote:
3) The code part in CbFsSetFileAttributes Code
...
does not make sense for me. Would the result not be the same if e.g. CreationTime was used directly ??.

Søren Kristensen wrote:
Do you have any documentation on what operationers are okay and what will give deadlocks in relation to the different callback functions ?

No, we don't. But it's safe to use operations that are "simple", i.e. only do some strict and simple work. For example a lot of stdlib functions, file i/o api, socket functions, etc. In opposite the functions like CreateProcess, OutputDebugString, MessageBox, etc are complicated - they internally communicate with different system components such as system services, etc. Perhaps some resource have been locked before or during some request to a CallbackFS storage and this resource will be released only when the request finishes. If in the callback (that is called to process the request) the same resource is tried to lock then a deadlock occurs. Sure the problem does not exist if these functions are called asynchronously.
Also it's easy to generate a deadlock if from a callback that is being processed a request from some CallbackFS storage, perform a request to the same CallbackFS storage (to the same file or directory). The latest request often will never finish because requests to the same file are consecutive and the callback for processing the previous request is being called already.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.