I need to find the underlying disk capacity (total size) of an unmapped network share in windows (in Win7, Vista, XP, Server 2008), given a UNC path (e.g. given something like "\\share_1\subdir").
I've looked all over the web for several days and seem to find no answer to this issue. I would appreciate any leads. Thanks in advance for your time!
I would have given up by now, if it weren't for the ability to find the underlying free space of unmapped network shares, using the "GetDiskFreeSpaceEx()" Win32 function. I imagine that disk capacity is stored in a similar fashion to free space, hence retrieving it would be very similar (hence I'm somewhat infuriated with MS for not making the functionality obvious, or myself for not being able to find it thus far!)
Regards,
vivri
You are on the right track. GetDiskFreeSpaceEx will also display capacity, you just have to call the correct members.
See this Microsoft support link on how to do it.
Keep in mind that GetDiskFreeSpaceEx may only retrieve the free disk space by user. For instance, Windows Explorer uses GetDiskFreeSpaceEx also and it may not report the actual free physical disk space, but rather the user's logged in quota.
Related
Is there any way to figure out which application is using up all the desktop heap memory?
For an explanation of 'desktop heap' see this MSDN blog.
EDIT: If you don't know what "desktop heap memory" is please don't answer.
EDIT2: if you don't know what "desktop heap memory" is don't vote to close the question.
Disclaimer: I work for Microsoft, and these are my personal thoughts and experiences which may or may not reflect current or future Microsoft policies/procedures/etc.
I know this is old, but since I stumbled across it I wanted to provide some feedback/answers.
Desktop Heap Monitor does not work on Vista+. DHeapMon depended on the ability to patch kernel binaries to track desktop heap- this behavior is blocked, which is why it doesn't work.
To monitor desktop heap yourself, all you can do is look at user objects (unfortunately).
To get a complete answer, you can open a support ticket with Microsoft and with a kernel or complete dump (NOT a process dump!) and they can inspect the heap and provide you some information. It is extracted from the dump file via a debugger extension, which I wrote.
Limitations:
Only works from kernel mode. Even though a desktop heap mapping exists in user mode, the extension does not support it. Even if I added support for user mode debugging of desktop heap, it would be limited as some of the related data is only in kernel mode. Changes on recent builds of Windows 10 might restrict it further, so I have not invested time to add user mode support.
It can't measure what isn't in the dump. In other words, if the desktop heap is missing pages it will do its best but it will obviously lose accuracy.
Does not support Windows 10 build 1809 or Server 2019, yet, due to changes to the heap manager.
Happy coding!
According to this blog post you should look for the user objects.
To find the bad application you can configure the USER Objects column within Process Explorer. Then sort descending by user objects. User Objects are all GUI objects like Windows, Toolbars, Icons, Cursors ... The process with the highest values is very likely the bad one.
Direct link to download: DHeapMon from microsoft.
If you want to do it within your program, C++ can use WMI to find the culprit.
I'm using a commandline tool to do some processing on a file. The thing is that this file should not be stored on disk (security reasons). So I was wondering whether it's possible in Windows to use a part of memory as a virtual file that is accessible bu the commandline tool as if it was a real physical file.
Yes, it's possible with things referred to as "ramdisks" usually. What's the best ramdisk for Windows? over at superuser.com has some links.
Have you written the command line tool yourself? If so, you can simply allocate a section of memory to your program and use it in your processing. There's little reason to trick the app into thinking it's using a file on a physical disk. The specifics on how to do so depend on what language your app is written in.
If not, you'll need to create a RAM disk and tell the program to use that. Using a RAM disk on Windows requires third-party software; a comprehensive list of options is available here on Super User.
Note, though, neither using a RAM disk nor storing all of your data in memory will make it more secure. The information stored in RAM is just as accessible to prying eyes and malicious applications as data that is saved on the hard disk. Probably more so than data that has been deleted from the hard disk.
If you need a ready to use application, there are several ramdisk applications (including free ones) on the market, and then your question here is offtopic. If you need to do this in code, than one of our virtual storage products (SolFS, CallbackDisk, Callback File System) will work, and Callback File System has a sample project that stores files in memory.
If you're using .NET, you might look into MemoryStream.
Note Cody Gray's answer though, which is only too true insofar as having something in memory does not guarantee that it can't be compromised. Though opinions differ on this subject. Most people would argue that writing to disk is even less secure, especially in the age of wear-levelling where controlling what is deleted and what is not is practically impossible.
RAM has its own disadvantages, but on the positive side, what's gone is gone :-)
I know that storage is available via Isolated Storage, but I'm not sure I've seen anywhere how much actual storage I have access to for my app. Anyone know?
Your application isn't limited to a certain amount of disk space or any quota (like on "full" Silverlight). You can, in theory, keep adding files/using disk space until the device runs out.
You can test for available space with IsolatedStorageFile.AvailableFreeSpace.
You should be careful about using all available space as it will impact other apps and general device performance. Hopefully the OS will stop anything horrible happening if you did use all free space but best to try and avoid being the cause of this.
There are some limits on the number of fies and directories you can have but you're very unlikely to hit these. Details at http://dotnetcatch.wordpress.com/2010/09/08/wp7-how-many-files-does-it-take-to-crash-isolatedstorage-more-than-you-think/
MS says a minimum of 8GB but devices may have more installed
http://msdn.microsoft.com/en-us/library/ff637514(v=VS.92).aspx
There are no limits for a single app
[EDIT] There IS a limit for a single app:
2 Gigs is the total size your app can grow to.
http://www.imaginativeuniversal.com/blog/post/2010/10/04/20-50-90-400-and-2.aspx
Just wanted to add that OS will start screaming when only 10% memory is left.
A system I have come across, that uses active directory, and has disk quotas, does not have the quotas tranparent to the user. All the users displays in windows (my computer etc.) and calls to GetDiskFreeSpaceEx always return the free space of the volume, and yet the user can never fill this free space because of the quotas. I have not been able to figure out anyway to know the size of the quota, and on the users PC's we have not been able to achieve anything to get these values.
It seems like somehow the quotas are applied on a directory level - and then users are limited to writing to certain directories. So the users quotas always show up as the free space on the disk, even though they cannot really write anything near this amount to any of the directories they have access to.
Has anyone come across something like this and know a winapi/msdn article about this. I am trying to write my program to figure out what free space a mapped active directory drive has for the user.
If you need to do anything to do with administration on Windows the place to start looking is usually WMI. There's a class called Win32_DiskQuota that has a Limit property.
This Technet blogpost have some sample code for calling this method from VBScript, which wouldn't be that hard to translate to C# or VB.Net (look at System.Management), or if you prefer C++, here's some samples showing how to use WMI from C++.
I am trying to investigate the behaviour of the Windows Kernel with respect to Memory Mapped Files / Virtual Memory. Specifically I am interested in determining how frequently the contents of a memory mapped file are flushed (by Windows) to disk and what criterion Windows uses for deciding it is time to do so.
I have done a bit of research online and, apart from the MSDN which deals more with the 'hows and whys' rather than detailing the internal workings, there doesn't appear to be much information. If anyone can point me to any articles or has looked into this before and has some insight I would welcome it.
Thanks.
I suggest reading Microsoft Windows Internals by Mark Russinovich and David Solomon, in fifth edition also with Alex Ionescu.
Memory mapped files are controlled by the modified page writer in the kernel - they're flushed whenever the memory that backs the page needs to be re-used (so it can happen under memory pressure).
The system also keeps track of the number of dirty pages and writes them after a threshold is reached.
You can find more information about in this article about Windows memory management changes for Windows Vista - it doesn't directly answer your question about how the memory manager treats modified pages but you can infer some of the details based on the information in the article.
The internal workings are an implementation detail and subject to change. They're not documented anywhere because Microsoft doesn't want you relying on the details.
I've got to ask: Why do you care? If you have hard real-time requirements, Windows might not be the OS for you...
I would suggest that you obtain a copy of
Microsoft® Windows® Internals
Fourth Edition: Microsoft Windows Server 2003 Windows XP and Windows 2000
There are pdfs floating around in the cyber cloud.
This is the book done by the "sysinternals" crowd who have written some very good windows utils over the years.
http://www.microsoft.com/technet/sysinternals
You will have to read the chapters on
Memory Management
Storage Management
Cache Manager
File Systems
They don't directly address your concern but if you manage to read, digest and grasp the very techical paragraphs you can work it out yourself. However if you can predict why Windows does what it does "You are a better man than most".
Happy brain freeze reading that lot.