EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Evaluation issues on Vista x64

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#8419
Posted: 12/09/2008 10:33:40
by Simon Smith (Basic support level)
Joined: 12/09/2008
Posts: 4

To evaluate the products suitability we've created a read only virtual disk that interfaces to our hardware. To this end, functions only "pass" if the file exists, otherwise we throw ECBFSError(ERROR_FILE_NOT_FOUND), and our RenameOrMoveFile always throws ECBFSError(ERROR_ACCESS_DENIED).

EnumerateDirectory caches the full directory search results from the virtual FS on the initial call under the context pointer, then moves through the list as the function is called again until it's processed them all. I free the memory allocated for my context in the CloseEnumeration call, but if I free it if no more files are found in the EnumerateDirectory call (Like the mounter sample does) in release it crashes as seemingly unmount is called before the final enum call finishes (according to the stderr diagnostic output I added). Memory locations of 0xfeeefeee tend to point towards this as well. If I comment the freeing of memory out in the enum function (so only the CloseEnum call frees memory) this problem seems to goes away.

Another issue is that it will crash in CbFsUcbQueryDirectory in a MemCpy call fairly reliably after clicking around the FS in Windows Explorer - again, only in release. I do not know why this happens.

A third issue is that quite often I receive a "The semaphore timeout period has expired (with "Location no longer available" in the title bar). Click around a bit more and back to that directory and goes away. You can make the OS think it needs to format your device this way, but that seems to be quite rare (and random).

SetFileSystemName does not seem to work either - it always displays Fat32. The order in which we set up the system is as follows, where g_pwszFileSystemName is our own FS name:

g_cfs.SetStorageCharacteristics(CallbackFileSystem::scReadOnlyDevice) ;
g_cfs.SetStorageType(CallbackFileSystem::stVirtualDisk) ;
g_cfs.CreateStorage() ;
g_cfs.AddMountingPoint(wszDrive) ;
g_cfs.MountMedia(g_nTimeout) ;
g_cfs.SetFileSystemName(g_pwszFileSystemName) ;

Finally, I have had 2 BSOD's *only* whilst in release builds alongside the above set of problems. Vista has probably cached the dump files away somewhere on the HD if anyone is interested in looking at them.

Perhaps I am doing something fundamentally wrong, but according to the (pretty scant) documentation I think I am using the API correctly. Could anyone help out here as so far we're not having much joy with using CFS as a file system solution - especially since we've had the Open Source Dokan up and running in about an afternoon under the same scenario (ie, read only FS mapping onto our hardware).

Build & Version info:
Version 2.1.43 (API reports 131073.2818164 for hi.lo driver version)
Release x64 build - VS 2008, C++ windows console application.
VC2005\64bit\x64\static_runtime(MT) linked.
Windows Vista Ultimate (SP1) 64bit.

Cheers,
Simon.
#8420
Posted: 12/09/2008 11:36:48
by Eugene Mayevski (EldoS Corp.)

Thank you for the report. First of all I should note that it's very easy to crash the OS or cause other unpredictable results if you make a mistake in callback handlers. The reason is that when the callbacks are called, the system is in very unstable state waiting for the kernel request to be handled. And instead of processing the IRP Callback File System does the extremely strange (from the OS point of view) thing - it switches to user mode to handle the request.

Quote
Simon Smith wrote:
EnumerateDirectory caches the full directory search results from the virtual FS on the initial call under the context pointer, then moves through the list as the function is called again until it's processed them all. I free the memory allocated for my context in the CloseEnumeration call, but if I free it if no more files are found in the EnumerateDirectory call (Like the mounter sample does) in release it crashes as seemingly unmount is called before the final enum call finishes (according to the stderr diagnostic output I added). Memory locations of 0xfeeefeee tend to point towards this as well. If I comment the freeing of memory out in the enum function (so only the CloseEnum call frees memory) this problem seems to goes away.


It looks like the context is used by your code after you free it. Just check that it's not. Or free it in OnCloseEnumeration.

Quote
Simon Smith wrote:
Another issue is that it will crash in CbFsUcbQueryDirectory in a MemCpy call fairly reliably after clicking around the FS in Windows Explorer - again, only in release. I do not know why this happens.

A third issue is that quite often I receive a "The semaphore timeout period has expired (with "Location no longer available" in the title bar). Click around a bit more and back to that directory and goes away. You can make the OS think it needs to format your device this way, but that seems to be quite rare (and random).



Again, this looks like something is wrong in your code. It's hard to say anything without having the actual test case. If you can reproduce the issue in a *simple* test case which doesn't require or rely on third-party hardware or software, - feel free to post it to HelpDesk for investigation.

Quote
Simon Smith wrote:
SetFileSystemName does not seem to work either - it always displays Fat32.


Don't change the FS name - doing this will stop many OS functions from working. The OS requires that the FS name is either FAT32 or NTFS, otherwise some things like running the applications under administrator account and more things won't work. The developer will give you more details.

Quote
Simon Smith wrote:
Finally, I have had 2 BSOD's *only* whilst in release builds alongside the above set of problems. Vista has probably cached the dump files away somewhere on the HD if anyone is interested in looking at them.


Yes, if you have them, please post them to HelpDesk.

Quote
Simon Smith wrote:
Could anyone help out here as so far we're not having much joy with using CFS as a file system solution - especially since we've had the Open Source Dokan up and running in about an afternoon under the same scenario (ie, read only FS mapping onto our hardware).


:) We have several customers who tried Dokan and faced the problems which were solved in CBFS long time ago. So you are welcome to rely on open-source...until you find a problem, and then you understand that you have wasted time on it and you have to start from the beginning.


Sincerely yours
Eugene Mayevski
#8428
Posted: 12/10/2008 01:56:52
by Simon Smith (Basic support level)
Joined: 12/09/2008
Posts: 4

Quote
Eugene wrote:
It looks like the context is used by your code after you free it. Just check that it's not. Or free it in OnCloseEnumeration.


Our context is a cache of the directory listings retreived from the initial enum call. We don't access it elsewhere, only copy details from the cache into the passed structures of the enum call as required. We only access the data when requested in the enum callback, so I can only surmise that CBFS is requesting more data after we have returned FALSE in the FileFound parameter. I notice that in the OnCloseEnumeration we can free our memory, but not NULL the context pointer (like you can from within the enum callback, where the address of the context pointer is passed).

Quite why we have to free the memory in the OnCloseEnumeration rather than when no more files are found in the enum call (like in the mounter sample) is a bit of a mystery, more so as the sample also has SetSerializeCallbacks(false) set. Could you expand on the "used by your code after you free it" statement please, taking what I said above into acount?

Quote
Eugene wrote:
Again, this looks like something is wrong in your code. It's hard to say anything without having the actual test case. If you can reproduce the issue in a *simple* test case which doesn't require or rely on third-party hardware or software, - feel free to post it to [URL=http://www.eldos.com/support/ticket_list.php]HelpDesk[/URL] for investigation.


I'll see if I can repro on a simple case that does not require 3rd party hardware. I have a suspision that there is something subtle up with our codebase (nobody else has these issues I guess) but it seems to be quite hard to track down on such a seeming simple scenario we have set up. Could it be related to return calls from other functions in some subtle way?

Quote
Eugene wrote:
Don't change the FS name - doing this will stop many OS functions from working. The OS requires that the FS name is either FAT32 or NTFS, otherwise some things like running the applications under administrator account and more things won't work. The developer will give you more details.


This is a data storage scenario, so only data access will occur (nothing will be run from the virtual file system). What OS functions will not occur properly? Would it be better to remove this functionality if it will just break the OS?

Quote
Eugene wrote:
We have several customers who tried Dokan and faced the problems which were solved in CBFS long time ago. So you are welcome to rely on open-source...until you find a problem, and then you understand that you have wasted time on it and you have to start from the beginning.


Could you expand on that please? What functionality/solved problems does CBFS have over something like Dokan (apart from full technical support of course!) These sorts of known issues are invaluable whilst evaluating potential options.

Thanks,
Simon.
#8429
Posted: 12/10/2008 02:15:03
by Eugene Mayevski (EldoS Corp.)

I am leaving several of your questions for developers to answer as I don't know the code to the necessary depth.

Quote
Simon Smith wrote:
This is a data storage scenario, so only data access will occur (nothing will be run from the virtual file system). What OS functions will not occur properly? Would it be better to remove this functionality if it will just break the OS?


I asked the developer (after answering you) and he said that the functionality to change the FS name was not disabled so you should be able to specify the file system name. The problem seems to be caused by OS/Platform combination and maybe code optimization in release version (optimizer sometimes can bring the errors).
As for the problems with file system names - the one that I remember (and it's mentioned in documentation) is impossibility to start applications that need to be run as administrator. Also, AppleTalk shares don't work if the file system [name] is not NTFS. That's all the developer could remember of but maybe there are more. Probably they are so specific that we didn't put them to

Quote
Simon Smith wrote:
Could you expand on that please? What functionality/solved problems does CBFS have over something like Dokan (apart from full technical support of course!) These sorts of known issues are invaluable whilst evaluating potential options.


The one I can remember (because it was described just a couple of days ago) are problems with MS Office which doesn't work correctly with Dokan storages. MS Office indeed requires fine-tuning of the driver and this the thing that we spent certain time. Next thing is how the library deals with Exporer which attempts to read file data when you browse the directory. In CBFS we use so-called network shares, for which Explorer reduces the number of reads. There are other technical benefits that CBFS offers, but frankly speaking I am not keen on seriously comparing some hobbyist work with the product developed by highly skilled professionals with more than 10 years of experience in component development.


Sincerely yours
Eugene Mayevski
#8430
Posted: 12/10/2008 02:36:52
by Eugene Mayevski (EldoS Corp.)

BTW you have mentioned the documentation was scant for you. What would you like to see there? Please ask questions and/or suggest topics, and we will answer and add the corresponding information to the documentation or knowledgebase (btw did you check the knowledgebase as well?)


Sincerely yours
Eugene Mayevski
#8431
Posted: 12/10/2008 06:40:03
by Simon Smith (Basic support level)
Joined: 12/09/2008
Posts: 4

I can reproduce the crash in CbFsUcbQueryDirectory every time now and have had a chance to rule out some options. The errors below are from linking with multi-threaded debug dll CRT (/MT) in a 64bit release build. It is also your library in the path linked to C:\Program Files (x86)\EldoS\Callback File System\CPP\VC2005\64bit\x64\dynamic_runtime(MD)\cbfs.lib.

First type of error encountered:

Critical error detected c0000374
This may be due to a corruption of the heap
(Allocation was going to be for over 2mb of memory).

The second is inside memcpy, again called from CbFsUcbQueryDirectory. It is trying to copy 0x0c bytes from one location to another. The memory addresses are stored in registers, but as the error is a access violation in reading location 0xffffffffffffffff, this would map onto the one register that is trying to dereference freed memory (ie, dereference 0xeefeeefeeefeeefe). The other location contains what looks like a valid unicode string representing a previously reported directory. (ie, one from our file system). I assume the latter memory is being reused.

Now, I have removed *all* deletes of memory that I allocated and stored within a context pointer, therefore I can surmise that the memory that was deleted (and now trying to be accessed) comes from your code and not mine.

Interestingly, as a slight aside, there a smattering of 32 and 64 bit values within the freed memory that (one assumes) have been erroniously written to as well.

Anyway, I hope this will help shed some light on it for you. I am now going to attempt to remove all our propriatory API calls out and replace with dummy calls so that I can produce a standalone sample that can crash in a repeatable manner for you.

Cheers,
Simon.
#8432
Posted: 12/10/2008 06:50:26
by Eugene Mayevski (EldoS Corp.)

Thank your for the detailed description of the issues, I will move the message to HelpDesk for deeper investigation. Vladimir Zinin, our CBFS driver developer, has already started to investigate your reports that you have posted. He will answer you as soon as he has anything to say :). Thanks again.


Sincerely yours
Eugene Mayevski
#8451
Posted: 12/11/2008 08:25:55
by Simon Smith (Basic support level)
Joined: 12/09/2008
Posts: 4

For others that may have this issue, it looks like it was because I had the timout in MountMedia set to be small (but non zero).

This came about because I saw "30" in the help file an put that in - what I misread was that you need to pass the value in as milliseconds.

Another issue solved - it seems that on Vista x64 the limit for a file system name is 10 characters. Any more and it will revert it back to FAT32.

Simon
#8452
Posted: 12/11/2008 08:43:36
by Volodymyr Zinin (EldoS Corp.)

During the development I recommend to set the timeout to 0 (i.e. infinite). This will help to avoid rising of timeout during debugging of the callback functions code.
#14275
Posted: 08/23/2010 11:31:45
by Kurt Griffiths (Standard support level)
Joined: 12/08/2008
Posts: 34

Simon, did you ever discover the problem with the CbFsUcbQueryDirectory memory corruption? I had no problem until I upgraded to CBFS 3.0 and now I am getting crashes very similar to what you reported.
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 10484 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!