When I use it (its source code is available at https://github.com/Zero3K/ERAM) in a Windows 10 64-bit virtual machine (in driver signature enforcement disabled mode) with it configured to use 100 MB for a RAM Disk and is set as a fixed disk via its cpl, I get a FAT_FILE_SYSTEM/SYSTEM_THREAD_EXCEPTION_NOT_HANDLED blue screen. I was able to make an analysis of it via WinDbg which is available at https://pastebin.com/MUBtSmcg. There’s also a list of defects found when building it with WDK 7.1.0 which is available at https://pastebin.com/tuf48eHn. Maybe someone could look at its source code to see what is causing it and then offer a fix.
>
>>>Maybe someone could look at its source code to see what is causing it
and then offer a fix.<<<wtf. noone has time and is motivated to browse thru others source code and
fix problems. i can make you an offer and fix the problem…
mp
You can’t assume that no one has time or motivation.
Zero3K wrote:
When I use it (its source code is available at https://github.com/Zero3K/ERAM) in a Windows 10 64-bit virtual machine (in driver signature enforcement disabled mode) with it configured to use 100 MB for a RAM Disk and is set as a fixed disk via its cpl, I get a FAT_FILE_SYSTEM/SYSTEM_THREAD_EXCEPTION_NOT_HANDLED blue screen. I was able to make an analysis of it via WinDbg which is available at https://pastebin.com/MUBtSmcg. There’s also a list of defects found when building it with WDK 7.1.0 which is available at https://pastebin.com/tuf48eHn. Maybe someone could look at its source code to see what is causing it and then offer a fix.
It isn’t necessary to look at the source code. The dump analysis
includes enough information to diagnose it. The github site claims to
show screenshots from a 64-bit system, but the code in the repository
could not possibly have been run at 64-bits. This is from the dump
analysis:
3013: }
2.
3014: }
3.
3015: /* Write the FAT sector */
4.
3016: pdwFatSector = (PDWORD)((ULONG)pBootFat16 +
pBootFat16->BPB.wNumResvSector * SECTOR);
5.
> 3017: pdwFatSector[0] = 0xffffff00 + pFatId->BPB.byMediaId;
6.
3018: if (pEramExt->FAT_size == PARTITION_FAT_12) /* FAT12 */
7.
3019: {
8.
3020: if (pEramExt->uOptflag.Bits.MakeTempDir != 0) /*
TEMP creation */
9.
3021: {
10.
3022: /* Make cluster 2 in use (total 36bits) */
Notice line 3016. pBootFat16 is a copy of pDisk which came from
pEramExt->pPageBase which was allocated with ExAllocatePool. That means
it is a 64-bit kernel address. Line 3016 stupidly casts that to a
(ULONG), thereby throwing away the top half of the address. A crash is
inevitable.
This stupidity occurs in many places throughout the code. You should go
look for a better RAM disk example, this one is hosed.
It did work on Windows 7 x64 before. The screenshot of its benchmark ran under a Windows 7 x64 VM was made by me. I’ll try seeing if it still works soon.
Zero3K wrote:
It did work on Windows 7 x64 before. The screenshot of its benchmark ran under a Windows 7 x64 VM was made by me.
Not with that code base. The ReadPool and WritePool routines have the
exact same problem as EramMakeFAT – they are 32-bit only. Is it
possible you’ve lost a commit?
As a general rule, don’t ever cast a pointer to an integer to do pointer
math. Just cast to a (char *). That will always work, and avoids any
32/64 nonsense.
- I didn’t lose a commit.
- How do I do that?
Zero3K wrote:
OSR https://community.osr.com/
Zero3K commented on BSOD occurring in ERAM (Open Source RAMDisk driver)* I didn’t lose a commit.
Well, I’m telling you this code could never have worked on a 64-bit
system. Perhaps you never triggered EramMakeFAT before.
* How do I do that?
Seriously? You couldn’t figure that out from my description???
pdwFatSector = (PDWORD)((ULONG)pbootFat16 +
pBootFat16->BPB.wNumResvSector * SECTOR);
becomes
pdwFatSector = (PDWORD)((char*)pbootFat16 +
pBootFat16->BPB.wNumResvSector * SECTOR);
or if you are really enamored with the Microsoft type aliases:
pdwFatSector = (PDWORD)((PBYTE)pbootFat16 +
pBootFat16->BPB.wNumResvSector * SECTOR);
I changed it and now I am getting an error stating “1>c:\eram\eram.c(3016) : error C2065: ‘pbootFat16’ : undeclared identifier”.
Zero3K wrote:
I changed it and now I am getting an error stating “1>c:\eram\eram.c(3016) : error C2065: ‘pbootFat16’ : undeclared identifier”.
Honestly, if you can’t fix that problem then you have no business coding
in kernel mode.
The identifier is being defined in the .h file. Where else does it need to be identified?
Mr. Zero3K… are you a professional software developer?
Serious question. No sarcasm or disrespect intended.
I ask because this is a peer help forum for software engineers who work in kernel mode. If that’s not you (like, maybe, you’re a student) then you’re welcome to post questions here, but we ask that you please identify yourself.
Peter
- I’m not a software developer. I’m just a user who is wanting to get this driver to work properly and am willing to learn how to fix it.
- What if it were to be made to format to a different FS or just leave it as RAW? Would that fix the BSOD?
Zero3K wrote:
I’m not a softwware developer. I’m just a user who is wanting to get this driver to work properly and am willing to learn how to fix it.
You should check out ImDisk, http://www.ltr-data.se/opencode.html/ . No
coding required.
> I’m not a software developer. I’m just a user who is wanting to get this driver
to work properly and am willing to learn how to fix it.
Well, such a fix can be hard even for experienced software developer.
May I ask you why do you need ramdisk driver and why just this one? Maybe your original problem has some simpler solution.
Michal
It looks faster than Ultra RAMDisk and ImDisk according to benchmarks I ran when it was working.
It would be nice if someone could help me get it built with AppVeyor.
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
>