I am developing a Windows driver, which will likely run on mostly Windows 7 machines, and possibly Windows 10 in the future.
Is it possible to create a full memory dump within the context of the driver (kernel mode)? Will the method used be the same for both Windows 7 and 10?
Related
I run the same application on Windows 10 and Windows 7 (both 64-bit) and used Process Explorer to monitor the Virtual Size. I noticed that the Virtual Size of the application running on Windows 10 is much larger than running on Windows 7.
By using VMMap, in Private Data:
Windows 10 - 1 address with 4.2GB is reserved and not committed.
Windows 7 - 2 address with 15MB are reserved and not committed.
So my questions are:
Why there is a large memory has been reserved? Is it just a different memory management done by Win10 and Win7?
Or, there is something to do with the application that I ran? (The application has no problem to run on Win10 & Win7)
Is there any suitable indicator to track memory leak? (Eg: 'Committed' value in VMMap) It seems like so much discussion/argument on this :P
I am curious to know about the difference between memory management in Windows and Linux.Does Windows OS support paging or segmentation?
I trying to understand, If all processes cumulatively uses all RAM on Windows machine then every user is prevented even from log in to the system but that is not the case with Linux systems.
So how it's achieved in Linux system?
Additionally to the recent posts, Windows 10 also supports compressing of the RAM. that means, before Windows tries so SWAP out memmory on hard drive, it will try to compress the RAM
I have to maintain a WDF driver. This is a no-hardware driver: the driver use a disk file which is mounted as a Windows partition. All the data written to the disk are encrypted by the driver. The driver run in kernel mode.
The driver has been developed on XP and successfully ported on Vista and 7, 32 & 64 bits. I encounter one big problem on Windows 8. The driver lead to a fatal system error:
BugCheck 50, {ffffffffffffffd0, 0, fffff800002de33a, 0}
Probably caused by : Wdf01000.sys ( Wdf01000!FxDevice::DispatchWithLock+fa )
The problem occurs after deleting the device with WdfObjectDelete(). As long as the device is not deleted the driver run fine and there is no system error. When WdfObjectDelete has been called, the system crashes after a certain delay.
verifier detects no error in the driver. My questions are the following:
Is there anything special regarding WDF on Windows 8?
Is there any tool/technique that could help me finding the bug in the driver?
There shouldn't be anything specific to Windows 8 for this issue. I'd recommend starting to debug your driver with WinDbg via a remote system. With this you can set breakpoints, step through the code and most importantly get post-mortem information on the crash. Once you have connected a machine, and you can see they crash use analyze -v to get information. OSR is a great resource for BSOD debugging.
I have a VB6 application that uses FileNet Visual Workflo (on FileNet Image Services) for the workflow engine. All of our application code has been updated to work correctly on both Windows XP and Windows 7, but there is a performance problem on Win 7 when attempting to get work object information from FileNet.
Within the application are calls such as
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
to which I've isolated the performance issue.
APIVWAPI is defined via late binding as follows:
Set APIVWAPI = CreateObject("VWApi.Srv")
The
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
line takes approximately 40 times longer on the Windows 7 machine (Core i7 3.4GHz CPU 8GB RAM) as it does on a Windows XP machine (Pentinum 4 3.2GHz, 1GB RAM). This line (and those like it) is called multiple times when retrieving queue items. As an example, a 120 item queue will take about 40 seconds to load on Windows 7 and <1 second on Windows XP.
Both systems are using the latest FileNet IDM components (4.0.3 fix pack 1). The Windows 7 environment is 64-bit Enterprise. XP is 32-bit Professional. The FileNet Visual Workflo components are the last, version 3.6.
Does anybody have any experience with FileNet IDM on Windows 7, and/or dealing with performance problems that appear to be DLL related on Windows 7 - and suggestions?
It turns out that the performance issue was related to drawing a ListView on the screen. Making the ListView not visible while retrieving the data, and then drawing the ListView once all data was retrieved, greatly increased performance.
I'll chalk this up to differences between 32-bit and 64-bit systems.
What are the differences between windows service and windows driver ?
Don't they both run in kernel mode?
Don't they both run in session0 in win vista&7
Services do not run in Kernel mode. They often do run at a higher privilege level than Administrator (the NT_AUTHORITY\SYSTEM account,) but still in userland. Drivers, especially in Vista and later, more often than not will also run in userland (with the exception of graphics card drivers1.)