If you are taking the NetMon approach, I suggest you to use Wireshark
instead (sorry MS folks :-P), and subscribe to the wireshark-users mailing
list. I think there are a bunch of people there knowing a lot about SMB (the
protocol used for file sharing).
Have a nice day
GV
–
Gianluca Varenni, Windows DDK MVP
CACE Technologies
http://www.cacetech.com
----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 17, 2007 2:14 PM
Subject: RE: [ntdev] Microsoft Ramdisk Share
If I have to solve similar problem, I’d probably use Network Monitor to see
real communication at network level. If access to share is refused, there
could be visible the real reason. Years before when I worked on network
software it was surprisigly successful approach. It is good to know
something about protocols used but it may not be necessary; NetMon makes
very good job with decoding them. You can compare successful access to
different share with access to RamDisk and examine differences. It should
help to identify the point where the access was refused and at least an
error code.
Oh please don’t ask me about details, I didn’t have a need to use NetMon for
years and my memory leaks quickly 
Google is your friend.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, October 17, 2007 10:40 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Microsoft Ramdisk Share
>
> Thanks for the reply mm,
>
> I doubled checked, and simple file sharing is turned on for every machine.
>
> I also checked the guest account, and it is enabled on every machine.
>
> Bryan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi,
I saw you got some good pointers from others but I can share my experience
as well… I’m running the ramdisk on a Vista machine and the others are XP.
If you use the demo code from the WDK all users can not use the ramdrive.
This Doron has answered, and adding this line of code gives all users
access.
I modified the code and checked that normal users can use the drive.
Then I shared the drive. Adding Full Control to Everyone. Then I can access
and write to the share from my other computers in the domain.
I think the problem you get is more an access control problem than driver
problem.
Good luck!
Daniel
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 17, 2007 9:26 PM
Subject: RE:[ntdev] Microsoft Ramdisk Share
> Thanks Doron,
>
> I was kind of hoping that someone out there had messed around with
> Microsoft’s kmdf ramdisk example enough to have some experience with
> sharing.
>
> If you have messed around with it:
>
> Were you able to successfully share it like I have?
> Were you able to successfully access the share?
> Were other people on the network able to access the share?
>
> Any help you could give would be appreciated.
>
> Bryan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
I installed the ramdisk on Machine A, shared the drive letter and tried to access it from Machine B, and it gave me Access Denied.
I mapped the share to a drive Z: on machine B, attached filemon and got these entries for trying to access the drive:
explorer.exe IRP_MJ_CREATE Z:\ SUCCESS Options: Open Directory Access: All
explorer.exe IRP_MJ_DIRECTORY_CONTROL Z:\ ACCESS DENIED FileBothDirectoryInformation: *
explorer.exe IRP_MJ_CLEANUP Z:\ SUCCESS
explorer.exe IRP_MJ_CLOSE Z:\ SUCCESS
On Machine A, I receive these entries in filemon from the network request (W: is the ramdisk):
System IRP_MJ_CREATE W: SUCCESS Options: Open Access: Read-Attributes
System IRP_MJ_QUERY_INFORMATION W: SUCCESS FileBasicInformation
System IRP_MJ_CLEANUP W:\ SUCCESS
System IRP_MJ_CLOSE W:\ SUCCESS
System IRP_MJ_QUERY_VOLUME_INFORMATION W:\ SUCCESS FileFsVolumeInformation
System IRP_MJ_QUERY_VOLUME_INFORMATION W:\ SUCCESS FileFsAttributeInformation
System IRP_MJ_QUERY_VOLUME_INFORMATION W:\ SUCCESS FileFsAttributeInformation
It seems the dirctrl is getting ACCESS_DENIED on the client machine, which is strange that it is allowing the create, and succeeding, but denying the dirctrl.
I am hoping something here will give a clue to what is wrong, but in the meantime I will try using netmon or wireshark (or both) to see if I can learn anything new.
Thanks,
Bryan
I tried access a regular share with netmon running, and everything worked properly.
Then i tried to access the ramdisk with netmon running and all requests were issued and completed the same until, on the client side, a smb issued dirctrl was sent, but never received on the server side. It was just completed on the client side with ACCESS_DENIED.
So, just like with filemon, something is denying access during the directory list, what could it be?
Thanks,
Bryan
I wanted to bump this back up because I have recently revisited this problem, and I am still unable to successfully allow users to access the ramdisk share.
A couple of folks have suggested that it is an access control problem and not a driver problem. My question this time is, if it was an access control problem, then all other shares on that machine would be inaccessible, correct? But, all other shares on the machine can be accessed normally, which leads my to believe it is a driver problem. Am I wrong?
I added the line of code Doran suggested to no avail. Bbeyond that, I still don’t know what the problem is.
Any help is appreciated.
Thanks,
Bryan
> A couple of folks have suggested that it is an access control problem and
not a driver problem. My question this time is, if it was an access
control problem, then all other shares on that machine would be
inaccessible, correct?
Nope.
But, all other shares on the machine can be accessed normally, which leads
my to believe it is a driver problem. Am I wrong?
Possibly.
Rightclick on a drive in My Computer and select Sharing or Sharing ans
Security or whatever it happens to be called. Assuming you have a share set
up for the drive, you can click on Permissions and set individual
permissions for that drive. Normally you would probably set permissions for
Everybody, but you can set individual permissions for individual groups or
users.
Now, in addition to this there are some wider sharing things that might make
the whole system inaccessible.
Loren
Thanks for the reply Loren,
The system is most certainly accessible, no matter which users try from which machine, they can access any share, except the ramdisk. I have also checked the permissions and I have tried giving Everybody full access, giving individual users read-only access, individual users full access, etc. Nothing is allowing even me, the one that installed the ramdisk to be able to access the share.
Any other ideas to try are most welcome.
Bryan
Have you ever tried an OTHER ramdisk ? For example , the older ramdisk sample from Microsoft ( KB Article Q257405 ) or any similar
ramdisk that you can find ?
C.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, November 12, 2007 11:13 PM
Subject: RE:[ntdev] !)Re: Microsoft Ramdisk Share
> Thanks for the reply Loren,
>
> The system is most certainly accessible, no matter which users try from which machine, they can access any share, except the
> ramdisk. I have also checked the permissions and I have tried giving Everybody full access, giving individual users read-only
> access, individual users full access, etc. Nothing is allowing even me, the one that installed the ramdisk to be able to access
> the share.
>
> Any other ideas to try are most welcome.
>
> Bryan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I tried one called Gavotte ramdisk, and it works like a charm, allows sharing and everyone can have access. Also, the older microsoft ramdisk did work as well, it is just the kmdf one that I am having trouble with.
Thanks for the reply,
Bryan
>I tried one called Gavotte ramdisk, and it works like a charm, allows sharing and everyone can have access. Also, the older
microsoft ramdisk did work as well, it is just the kmdf one that I am having trouble with.
Then I think ( feel ) it has something to do with one or another IOCTL call to the driver that fails on the KMDF version. Perhaps it
will be necessary to trace ( add debug info ) both versions to see if there is a difference in the call sequences and return values
of those IOCTL calls.
C.
Thanks for the reply,
Bryan
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks for the reply,
I can check the debug messages to see if anything out of the ordinary occurs.
Specifically, assuming IOCTLs get sent down at all times, do you think I need to check the IOCTLs:
- When the ramdisk gets loaded?
- When it gets shared?
- When access is attempted to the share?
- All of the above?
Bryan
Well… start with 1. and 2. … and end with 4. . Personally , I would do 4. , log the debug messages to files , print
them out , put them on my desk , and compare the log files *logically* …
C.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, November 13, 2007 5:55 PM
Subject: RE:[ntdev] !)Re: Microsoft Ramdisk Share
> Thanks for the reply,
>
> I can check the debug messages to see if anything out of the ordinary occurs.
>
> Specifically, assuming IOCTLs get sent down at all times, do you think I need to check the IOCTLs:
>
> 1. When the ramdisk gets loaded?
> 2. When it gets shared?
> 3. When access is attempted to the share?
> 4. All of the above?
>
> Bryan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks for the help, I’ll try that.
Bryan
Hello again,
I got back to this problem finally, and I attempted to trace IOCTLs coming down to the ramdisk. I found one IOCTL that wasn’t getting completed, IOCTL_MOUNTDEV_QUERY_DEVICE_NAME. I went ahead and implemented it and tried testing again. I still get the same problem, I am unable to grant access to other users to the kmdf ramdisk share.
Any other ideas would be greatly appreciated.
Bryan
Another try…
To recap, I want to install the kmdf ramdisk example driver on a Windows XP machine and share it to allow other people on the domain to access the files and folders. I have no problems installing or sharing the drive, but do have problems when people try to access it.
Basically, when a user in the domain tries to access the ramdisk, they get an access denial message. After trying numerous things with different security parameters, I ended up using NetMon to see the messages getting passed back and forth and to pinpoint the problem.
I ended up finding out that the directory list being issued was getting returned with a STATUS_ACCESS_DENIED without going down to the filesystem on the ramdisk or the disk driver itself.
I went ahead and used FileTest to test creates, fileinfos and closes on numerous files/directories in the ramdisk over the network, and everything worked perfectly. The only thing that didn’t work is anything that requires a directory list to operate properly.
What would cause directory list, and nothing else, to be denied? Is there a flag or something on the device object that would allow this? Is there something else I am missing?
Also, who is returning the STATUS_ACCESS_DENIED for the directory list? I used kernel debugging and FileMon and didn’t see these requests coming down or being completed at all.
Any help would be appreciated.
Bryan
Bryan:
I am sorry that I have no further information for you, but you
definitely win the persistence award.
Good luck,
mm
xxxxx@hotmail.com wrote:
Another try…
To recap, I want to install the kmdf ramdisk example driver on a Windows XP machine and share it to allow other people on the domain to access the files and folders. I have no problems installing or sharing the drive, but do have problems when people try to access it.
Basically, when a user in the domain tries to access the ramdisk, they get an access denial message. After trying numerous things with different security parameters, I ended up using NetMon to see the messages getting passed back and forth and to pinpoint the problem.
I ended up finding out that the directory list being issued was getting returned with a STATUS_ACCESS_DENIED without going down to the filesystem on the ramdisk or the disk driver itself.
I went ahead and used FileTest to test creates, fileinfos and closes on numerous files/directories in the ramdisk over the network, and everything worked perfectly. The only thing that didn’t work is anything that requires a directory list to operate properly.
What would cause directory list, and nothing else, to be denied? Is there a flag or something on the device object that would allow this? Is there something else I am missing?
Also, who is returning the STATUS_ACCESS_DENIED for the directory list? I used kernel debugging and FileMon and didn’t see these requests coming down or being completed at all.
Any help would be appreciated.
Bryan
I’d suggest you try OSR’s ntfsd list for this issue (instead of ntdev).
The ntfsd list is read by more file system specialists.
BR -H
Brian:
Have you tried the pre-kmdf version of MS ramdisk? I imagine that you
have, but if not, considering that nothing else seems to be working, I’d
give it a try:
http://support.microsoft.com/kb/257405/en-us
I don’t know anything about it really, but even if it is not what you
really want, it might help you figure out what the problem is, whether
it works or not.
Good luck,
mm
Hagen Patzke wrote:
I’d suggest you try OSR’s ntfsd list for this issue (instead of ntdev).
The ntfsd list is read by more file system specialists.
BR -H