Forget it. Seriously. The code needs to be rewritten to support 64-bit Windows. You’re not going to do that, short of learning how to write Windows drivers, which can take “quite a while.”
Take Mr . Roberts’ advice and use a different package.
Peter
I’m back to waiting for someone somewhere else to get it working then.
I would suggest doing this via a virtual storport driver and not a disk
class driver. You are asking for trouble, and support nightmares with
future versions of Windows.
Just Don’t Do It!
On Tue, Nov 20, 2018 at 1:55 PM Zero3K
wrote:
> OSR https://community.osr.com/
> Zero3K commented on BSOD occurring in ERAM (Open Source RAMDisk driver)
>
> I’m back to waiting for someone to get it working then.
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/291516#Comment_291516
>
> Check it out:
> https://community.osr.com/discussion/comment/291516#Comment_291516
>
Why are you telling me that?
Zero3K wrote:
I’m back to waiting for someone to get it working then.
You’re going to wait a very long time. Virtually everyone on this list
writes drivers for a living. We get PAID to do driver work. Fixing
someone else’s old and broken code isn’t much fun and doesn’t pay the bills.
Why are you so married to this bogus code? Presumably, you have a
problem to solve, and you believe that problem needs a RAM disk. We
have already told you, there are other RAM disks that will do the job in
a safe and reliable way. You didn’t write this code, and you don’t have
the ability to maintain it, so what is it to you?
Its because there aren’t that many good open source RAM Disks. I just want to be able to have it working so it’ll be an alternative to them.
Zero3K wrote:
Its because there aren’t that many good open source RAM Disks. I just want to be able to have it working so it’ll be an alternative to them.
There are half a dozen. How many RAM disks does the world need? The
Windows file cache is so aggressive that a RAM disk is virtually useless
today anyway.
Look, if you want to learn enough about coding to get this working and
play with yourself, that’s a perfectly fine goal, but so far you have
shown ZERO interest in doing that. Your git repository is a clone of
someone else’s 10-year-old code base. It has been sitting there for 2
years, and you’ve done nothing to it except change some of the file
names. No one here has any interest in fixing it, because it has no
value. I can tell you have no interest in coding, because you couldn’t
even fix the one-character typo in the correction I already sent you.
If you’re not a driver developer, and it certainly looks like you are
not, then you do not belong on this forum.
Well, Zero3K now seriously, like I told you in some of the private messages that I sent you in the last couple of days and like others here are also trying to tell you, the code you are trying to get working is bad. It would take lots of time to rewrite it to something stable. You cannot constantly respond to that by saying “maybe it is just this issue”, “maybe if we just get this piece correct it might work”, because the code has many more issues than that. Which is pretty obvious for anyone with experience of this kind of code.
Now, if you step back a little and try to listen. Even if you have found that this code produces RAM disks with better performance than others you have tried it does not mean that it is better. It could be that other projects have been used and tested by many users for many years and that the code has evolved into something really stable and compatible but with some performance penalty, such things do happen. For kernel mode drivers, that could be essential. It is not just performance that shows that the code is good, it is also about comatibility and robustness in it.
I (and many other people on this list of course) have worked on other RAM disk projects for many years, both open and closed source projets, and I know that some of the things we have found the need to fix to make it stable have also unfortunately made it run a little slower in some scenarios. But it has been overall worth it to implement these changes anyway of course. It does not mean that the code is bad and it does not mean that some other random old code you might have found with better performance is “better” in general. So, like I said in another message, it might very well happen that if you get this particular code working and stable (which I doubt), it might be that it will then not perform better than other stable projects anyway.
So, please, try to step away from old buggy code. There are instead things like ImDisk which is a legacy style disk driver that has been around for almost 15 years now and Arsenal Image Mounter that has been around for about the same age as a scsiport miniport and for around 5 years as a storport miniport. There are others out there as well. Most important thing for you is to look at something well-maintained and that has been around for many years with lots of users and developers who hopefully have already tested and fixed the things that you see in this ERAM driver code right now. Don’t look at just performance because that’s not all when it comes to code quality!
It turns out that it was some simple changes that were needed after all. It now works without any BSODs so far after I changed some ULONGs to PBYTEs as instructed earlier. I will do some more testing in the VM to make sure.
I have gotten another BSOD to occur when loading it via Driver Verifier. It is stating that it happened because of " MmMapLockedPages called without MDL_MAPPING_CAN_FAIL". The analysis of it is available at https://pastebin.com/WsDeyNJu.
Zero3K wrote:
I have gotten another BSOD to occur when loading it via Driver Verifier. It is stating that it happened because of " MmMapLockedPages called without MDL_MAPPING_CAN_FAIL". The analysis of it is available at https://pastebin.com/WsDeyNJu.
Did you do ANY web searching at all before posting this question?
Google is way faster and a lot less cranky than this forum.
This is what happens when you take code written for Windows 2000 and run
it on a 21st Century system. There is a 4-character fix that you need
in two places in your code.
I did search Google and didn’t find the answer I was looking for. I guess I didn’t search hard enough or I used the wrong terms.
Zero3K wrote:
I did do Google searching. I didn’t find the answer I was looking for. I guess I didn’t search hard enough.
I hope you noticed that your code never actually calls
MmMapLockedPages. Did you check the dump to see exactly which line
caused the problem? It tells you that. If you find the line that
caused it, and look up that call, you should be able to find the answer.
All I saw is that MmGetSystemAddressForMdlsafe should be used instead of MmGetSystemAddressForMdl. I tried that and it didn’t compile. Can you just please tell me the fix?
Zero3K wrote:
All I saw is that MmGetSystemAddressForMdlsafe should be used instead of MmGetSystemAddressForMdl. I tried that and it didn’t compile.
Yes. And your next step should have been to look at the documentation,
which would have shown you that the Safe version requires an extra
parameter.
Okay. I should’ve searched for it. Thanks for pointing me in the right direction. Now to see if it BSOD’s again or not.
Don’t worry it will BSOD again, I didn’t jump into the conversation earlier but I had gotten curious and run some code analysis on the driver, my guess is you have at least 500 more lines to fix. And of course once you do that you still will have a driver that was written for an obsolete model as has been pointed out way to many times in this thread. No, I am not going to post my analysis, that would be like sticking wings on a pig (check the OSR websites for the reference).
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
Oh the ram disk is a great add on to the buffer cache. What better way to
ensure data loss and file corruption than lying about when things have
actually been written to non volatile storage?
Mark Roddy
Don_Burn: It hasn’t BSOD again (so far). The only issue I am running into now is that after copying some files, it stops allowing files to be copied when its formatted with a FAT32 file system (it just either gets stuck copying or gives an error for the rest of the files).
Mark_Roddy: I know how RAM Disks work. Which is why I am using Drive Snapshot to back it up every night and on restarting (if possible) and then restore it before the rest of the programs that run on start are ran.
This is a fools errand.
Helping random users fix problems in code they know nothing about, using skills they prefer not to have, is NOT THE PURPOSE OF THIS FORUM.
I’m as sympathic to the OPs plight as the next guy, but this thread is totally and completely off topic. We don’t cater for end users, with no kernel development skillls, who need to refactor a driver. That’s not the goal of this forum.
So… I’m closing/locking this topic.
Sorry… but this is pointless and I do t want this forum to become “I don’t know how to write drivers, please tell me what to type”… any more than it already is.
Discussion hereby closed. OP put on moderation.
Pete