65 replies to this topic

[v77]

@Olof:

Bad news: the example that you previously pointed has worked because my system was "improperly" configured. To retrieve the SeLockMemoryPrivilege, we need to use AdjustTokenPrivileges and related functions, but also to enable this privilege in the local group policy. And I forgot that I played with that some times ago, without really to know what I was doing...

But I don't like the idea to ask the user to change its local group policy. As I already written a part of the code, I can still implement the thing "just in case", but this will likely not be a very used option.

[Olof Lagerkvist]

That's another thing I had forgotten, obviously. I also see this privilege assigned to my user account on some of my test machines here and I have certainly not manually assigned it. I thought there has got to be a reason and Googled around a bit. Found this:

 

http://sourceforge.n...thread/c03a6e7e
 

Indeed, on the machines where this privilege is assigned to my account, I have installed 7-zip.

 

But I agree this feels ugly in so many ways. Particularly the way 7-zip does this by assigning this privilege "just in case" the current user would like to use it some time in the future.

[v77]

Very interesting, thanks! I forgot to install 7-Zip on my laptop, and indeed, the privilege is not enabled. Just made a quick test on my desktop machine: starting 7-Zip with admin rights is enough to enable this right in the local group policy.
Of course, a more elegant solution than 7-Zip could be to add a button or something to enable that easily. I "just" have to find a way to programmatically do the same thing than 7-Zip.

[Olof Lagerkvist]

Very interesting, thanks! I forgot to install 7-Zip on my laptop, and indeed, the privilege is not enabled. Just made a quick test on my desktop machine: starting 7-Zip with admin rights is enough to enable this right in the local group policy.
Of course, a more elegant solution than 7-Zip could be to add a button or something to enable that easily. I "just" have to find a way to programmatically do the same thing than 7-Zip.

 
Basically, LsaAddAccountRights.
http://msdn.microsof...p/ms721786.aspx
Not exactly straight-forward to implement in my opinion. I would recommend looking at 7-zip source code (or similar) when this is already solved.
 
Edit: Probably not that complicated after all. There is some sample code that shows how to open a policy object that can later be used in the call to LsaAddAccountRights.
http://msdn.microsof...p/ms721874.aspx

[TheHive]

http://reboot.pro/to...ers-some-notes/

milindsmart

2) Why does everyone prefer to write SCSI drivers instead of plain old AHCI drivers? or is AHCI not "plain"? Even Olof Lagerkvist in Arsenal Mounter uses a(an?) SCSI driver, so there must be something about it.

 

http://reboot.pro/to...notes/?p=188504

[Olof Lagerkvist]

http://reboot.pro/to...ers-some-notes/
milindsmart
http://reboot.pro/to...notes/?p=188504

Answer: http://reboot.pro/to...notes/?p=188516

[friske]

From the command line I do not release the memory freed.

First I was wrong to write.

I use:

RamDyn.exe "M:" XXX 1048576 10 10 10 10

ImDisk.exe -a -o fix -o hd -o rw -m M: -p "/fs:NTFS /C /Q /Y /V:Alx" -t proxy -o shm -f RamDynXXX

 

Again: Often the committ cpu many often more than 90%

No response to this?

[v77]

No response to this?

 

Well... where is the question?
I am not sure to understand your first sentence. Do you mean that the RAM is not freed when you delete a file?
In that case, it depends on the size of the file and the parameters of the cleanup function (the 4 last numbers in the command line of RamDyn.exe). For instance, the first number is a ratio ( / 1000) of the total drive space, and the cleanup function is activated only if this ratio of memory to free is reached (this is approximate).
These 4 parameters are described in the tooltips of the dialog box you get with the "Dynamic RamDisk Cleanup" button of the RamDisk Configuration Tool.

[friske]

I Have a 1GB disk and delete a 200MB file but not free.

Often the committ cpu many often more than 90%.

I have Xp.

[v77]

Ah, sorry, I now understand, and I have reproduced the issue.

In the parameters for the format command, you are using the /C switch, which means a compressed NTFS file system. RamDyn is absolutely NOT designed for this kind of thing. It is designed for a file system where the space required for a file is the same than the space used in memory. Moreover, the compression can introduce some other issues, especially with the cleanup function.

So, you have to remove /C when you use RamDyn if you want tu use it properly.

[friske]

I understand

 

Minimal Amount of Data to Clean
Minimal Time between 2 Cleanups

 

but what does this mean

 

Security Margin
Maximal Activity before Cleanup
 

?

[v77]

As I said, there are tooltips for each value. Leave the mouse pointer onto a value and they will appear.

"Security Margin" is the space that will not be filled by the cleanup function. This function writes one or several files with a content of 0 to wipe out the whole space of volume. Even if it's very fast, a software may need to write something at the very end of this cleanup. In order to avoid an error of this software, we need to leave at least a small space available. Of course, this also means that if this space contains data that are no longer in use, they will not be freed.

"Maximal Activity before Cleanup" means that RamDyn checks the activity of the ramdisk before starting the cleanup function. Even if there is some memory to free, if you are using the ramdisk for copying big files, it's not really the best time to start a cleanup that uses CPU and RAM. That's why the cleanup function waits that read and write requests are below this value.

[friske]

 

I had a Server 2003 .. I thought it would make sense to try the /PAE switch and write a driver that attempted to allocate beyond the limit where Windows itself would allocate physical pages. This is what later became awealloc driver. This turned out to work so that I could allocate the "lost memory" above 4 GB through awealloc and use it as a virtual disk where I could create a pagefile. The conclusion was that Windows would never allocate physical pages above 4 GB on Standard Edition because of license based limitations. But it still allowed drivers to explicitly allocate any range of AWE addressable memory for there own purposes.

imdisk awealloc in PAE work only in Windows Server 2003 or also in xp?
awealloc work only on >4GB ram or also on >3GB?

[Olof Lagerkvist]

Awealloc works on XP too, but it cannot allocate above 4 GB there. It could be useful anyway, because it allocates physical memory that cannot be swapped out to disk.

[friske]

I'm sorry but I do not understand.

For example, I have, in Xp with 4GB, a ramdisk with Gavotte in which use the swap file with addswap.

I then see 3GB RAM + 1GB Swap.

I can do the same with ImDisk?

I always have to enable/ PAE?

What command line I have to give?

Can I control who Swap actually uses upper 3Gb ?

[Olof Lagerkvist]

I don't really understand the point with doing this. But you should be able to do something similar with ImDisk and awealloc:

imdisk -a -s 1G -o awe -m R: -p "/fs:ntfs /q /y /v:RAMDISK"
swapadd R:\pagefile.sys 900M 900M

This will simply use 1 GB physical RAM as a virtual disk with a swap file on it. Again, I don't see the point. What difference would this make?

[friske]

I want to be sure that the ramdisk with the swap uses memory upper than 3GB in xp that can not normally be seen and used by applications.

[Olof Lagerkvist]

Okay. I'm sorry but it doesn't work that way. You are confusing physical memory addresses that represent physical RAM, with virtual address space for each process.

Virtual address space is limited to 2 GB for user processes in 32-bit Windows. It can be extended to 3 GB by adding /3GB in boot.ini. Allocations within the virtual address space for an application can be committed and use physical memory at any address reachable by Windows, it could be stored below or above physical 3 GB, or in the paging file on disk. But the process is still limited to 3 GB virtual address space. To turn already usable physical memory into a swap file does not help in any way.

[friske]

Excuse my poor english. I not cure for process limited to 3 GB virtual address space. I'm just concerned that the swap file in ramdisk uses memory between 3 and 4 GB.

[Wonko the Sane]

I guess we are slowly drifting towards the good ol' pagefile yes/pagefile no/but it should be system managed/no, I want full control on it debate, very like the Godzilla vs. King Kong one.

 

Just to make a few clear statements (IMNSHO opinion they should be called "the absolute truth" ):

1. the pagefile is essentially a "mistification", a "poor man's replacement" for more RAM
2. XP came out at a time where the "standard" amount of RAM available on common machines was 128 or 256 Mb, very, very few had 512 Mb
3. in order to allow the stupid mass of bloat to work on these clearly underpowered machines, there was a "magic formula" amounting to have a pagefile on hard disk sized 1.5x to 2.x the amount of RAM or
4. let the OS manage it automatically and
5. even worse, let it be of "dynamic" size
6. a number of (usually "high end" third party) tools would not run without a pagefile (a known one among the others Photoshop)
7. the pagefile is also used for so-called RAM "system crash" dumps

Essentially, none of the above makes any actual sense, if not, partially, item #7.

 

If an OS *needs* RAM you should provide it with RAM and not give it instead a "replacement".

 

In an nutshell, IF the pagefile is hit (because there is not enough RAM in it's normal use) it is time to add more RAM or change Operating System and add more RAM.

 

Setting a pagefile as "dynamic" (on hard disk) makes NO sense at all, either you have enough space for it's maximum size or you do not, if you have it good and you can reserve it from the start in a "fixed" setting, if you don't, it's like having a small amount of dynamite under your chair, it is stable, it will never self-ignite, but IF it does, it will explode.

In case of a serious crash the risk of trashing data on the filesystem on the hard disk filling it up to the brim, is relevant.

 

Setting a pagefile as "dynamic" (on a RAM disk) is of course completely foolish, but even setting it as "fixed" on it makes little sense.

 

The only real reason why one may want to have a pagefile is (as seen above, points #6 and #7) for compatibility with a few stupid programs (but in this case there is no need for a "large" size pagefile, a very small one would do) and to have in case of crash a full memory dump, this latter might be useful in extremely rare events, i.e. in case of crashes.

 

Now there are two kinds of crashes:

• non-repeatable ones (call them "Acts of God" or "Voodoo", they simply happen )
• repeatable ones

the former ones are in practice non-resolvable, the latter ones, since they can be reproduced, allow for setting specifically a largish pagefile on hard disk to allow the full memory dump ONLY when you are troubleshooting the issue.

Of course since the use of a crashdump is to have access to it from another OS, the pagefile on a Ramdisk is not much suited for this, and in any case a 1 Gb pagefle on a 4 Gb RAM system would not hold the whole dump.

 

So, the only (maybe) reason where a (small) pagefile on a RAMdisk may actually make some sense is (while keeping the system compatible with the mentioned stupid third party apps) to make sure that no traces whatever of it are left at power off (actually after several seconds past it), i.e. for (rather paranoid) security reasons and of course it is completely vain, as "they" can read your mind the right moment you take off your tinfoil hat to shower and wash your hair.

 

Or - of course - another good reason is "just for the sheer fun of it" .

 

 

Wonko

 

a la Tapatalk :

 

[Sent from Opera, running under XP operating system with NO pagefile since 2007^[1]]

 

^[1]And before you ask, after having run Windows 2000 from 2003 to 2007 with NO pagefile. 

 

P.S.: And before I forget , the good ol' dinosaur can kick that grown up chimpanzee's @ss all the way to the moon and back with BOTH hands tied behind it's back, any time.

 

A semi-random couple links:

http://www.msfn.org/...le-at-shutdown/

http://mcpmag.com/ar...ws-systems.aspx

 

 

 

[friske]

I know what you say on the swap.
But if I have the unique opportunity to use the RAM 3 to 4 GB in XP by creating a swap, I do not see why not.
That way I could still exploit another GB for virtual memory.

[Olof Lagerkvist]

I know what you say on the swap.
But if I have the unique opportunity to use the RAM 3 to 4 GB in XP by creating a swap, I do not see why not.

It is pointless because that memory is perfectly normal RAM already accessible to your applications. Your applications can't use memory above 3 GB in their own virtual address spaces though, but that has nothing to do with physical addresses.

[v77]

Excuse my poor english. I not cure for process limited to 3 GB virtual address space. I'm just concerned that the swap file in ramdisk uses memory between 3 and 4 GB.

 

The physical memory must be managed by the system to be used with the AWE API (awealloc). As far as I know, XP does not manage the memory between 3 and 4 GB. So, awealloc cannot be used for that.
You need a ramdisk that uses "invisible" or "unmanaged" memory.

If you can install a 64-bit system, you will be able to use directly all your RAM without any restriction. This is a pity to have a 64-bit CPU and still use a 32-bit system...

[friske]

The physical memory must be managed by the system to be used with the AWE API (awealloc). As far as I know, XP does not manage the memory between 3 and 4 GB. So, awealloc cannot be used for that.
You need a ramdisk that uses "invisible" or "unmanaged" memory.

This was what I understood so far, but after reading this below, I had come to doubt.

This turned out to work so that I could allocate the "lost memory" above 4 GB through awealloc and use it as a virtual disk where I could create a pagefile. The conclusion was that Windows would never allocate physical pages above 4 GB on Standard Edition because of license based limitations. But it still allowed drivers to explicitly allocate any range of AWE addressable memory for there own purposes.

[Olof Lagerkvist]

The physical memory must be managed by the system to be used with the AWE API (awealloc). As far as I know, XP does not manage the memory between 3 and 4 GB. So, awealloc cannot be used for that.
You need a ramdisk that uses "invisible" or "unmanaged" memory.

No, Windows XP 32 bit handles 4 GB RAM.
http://msdn.microsof...mits_windows_xp

This was what I understood so far, but after reading this below, I had come to doubt.

That's another question. That applies to the situation with more than 4 GB RAM on Server 2003 Standard Edition, where the kernel obviously accept allocation of physical memory above 4 GB but would not use it for application memory commits.