Notebook

In my previous post, I tried to build a command line app to show Physical Hard drives and volume(s) mapping for each HDD present/attached to a system. Now I've extended the program to read and display the properties of the storage adapter for each physical hard drive. To achieve this I've used the very popular Win32 API, CreateFile(), and IOCTL_STORAGE_QUERY_PROPERTY control code. The previous program has been extended and now I'm showing only the part I've added on top of my previous program released under the title "PhysicalDisk and Volume Mapping information". Here goes the rest of the code to get the storage adapter's information: void PrintBusTypeName(BYTE iBusType) {     switch(iBusType)     {     case BusTypeUnknown:         wprintf(L"BusType: Unknown\n");         break;     case BusTypeScsi:         wprintf(L"BusType: SCSI\n");         break;     case BusTypeAtapi:         wprintf(L"BusType: ATAPI\n");         br

After a long time, writing this post on Windows Disk Management. I was playing with volume management APIs and found it's quite easy to get some useful information like, how I know what are the volume(s) present on a physical disk. I'm talking about a hard drive here. Of course, the Windows disk manager will reveal it but why not I should have my own app. There are Windows Volume Management APIs including the very famous CreateFile API, which is one of the amazing APIs on Windows provided by Microsoft. The objective was to build a tool that will tell How many HDDs are attached to the system with volume information. Here is the complete code: const int BUFF_SIZE           = 512; const int STR_SIZE              = 20; const int DRIVE_ID_BUFF = 3; int _tmain(int argc, _TCHAR* argv[]) {     TCHAR szTemp[BUFF_SIZE];         if (GetLogicalDriveStrings(BUFF_SIZE - 1, szTemp))     {         TCHAR szDrive[DRIVE_ID_BUFF] = TEXT(" :");         TCHAR* pDrive = szTemp;        

This is the extension of part 3. I'd like to explain few things in details.  In part 3 we started discussion on PEB_LDR_DATA structure. The more details  on it can be referenced in following MSDN article: http://msdn.microsoft.com/en-us/library/windows/desktop/aa813708%28v=vs.85%29.aspx As per MSDN, the structure looks like below: typedef struct _PEB_LDR_DATA { BYTE       Reserved1[8]; PVOID      Reserved2[3]; LIST_ENTRY InMemoryOrderModuleList; } PEB_LDR_DATA, *PPEB_LDR_DATA;   The highlighted part according to MSDN, "The head of a doubly-linked list that  contains the loaded modules for the process. Each item in the list is a pointer  to an LDR_DATA_TABLE_ENTRY structure."   The data type is LIST_ENTRY. According to MSDN, the structure is like below: typedef struct _LIST_ENTRY { struct _LIST_ENTRY *Flink; struct _LIST_ENTRY *Blink; } LIST_ENTRY, *PLIST_ENTRY, *RESTRICTED_POINTER PRLIST_ENTRY;   Let's see what WinDbg says about it.

In this post, I'd like to explore Loader Data which is part of Process Environment Block ( PEB ). This structure tells us what are the dlls are loaded by the process. To start with, I've loaded my sample program through WinDbg and all symbol paths are set. Then I've executed following command: !peb and received following output. (I've trimmed the output) for readability purpose. If we look at the PEB structure below, the highlighted one is important to us. This is basically a NT structure known as _PEB_LDR_DATA . PEB at 7efde000     InheritedAddressSpace:    No     ReadImageFileExecOptions: No     BeingDebugged:            Yes     ImageBaseAddress:         00400000     Ldr                       775f0200      <=========_PEB_LDR _DATA at 775f0200     Ldr.Initialized:          Yes     Ldr.InInitializationOrderModuleList: 00593288 . 00594308     Ldr.InLoadOrderModuleList:           005931e8 . 00594018     Ldr.InMemoryOrderModuleList:         005931f0 . 0

Microsoft has given ability to its development tool to suit the requirement as per developer wish. I had a requirement which needs to play multiple instances of media player on a single monitor. As a feature we know Media player can have only one instance running at a time. So I was scratching my head and finally a solution struck me, which is embedding multiple Media player instances on a single Win Form. I've used C#.net and Windows Media Player library to solve the problem. Let's a have a look in the below sample program, the code is quite self explanatory. This sample code created an array of 2 Windows Media player instances and playing two audio (mp3) files simultaneously. The Recreate button destroys the previous instances and creates two more new one. This is a very basic code and it can be modified as per more complex requirement. However, running large number of multiple instances of Windows Media Player isn't advisable. using System; using System.Collections

In this section, I’d like to disassemble our main function which we’ve written in series 1 and would like to see how it looks like. Also would like to see if we can see the string “Hello World”. I’ve launched my sample executable using WinDbg. Then Issued following command: x sample_hello!*main* *** WARNING: Unable to verify checksum for Sample_Hello.exe 00419048           Sample_Hello!__native_dllmain_reason = 0xffffffff 0041917c           Sample_Hello!mainret = 0n0 004114b0           Sample_Hello!wmain (int, wchar_t **) 004122b0           Sample_Hello!__tmainCRTStartup (void) 00412290           Sample_Hello!wmainCRTStartup (void) 00413592           Sample_Hello!__wgetmainargs ( ) 0041a3d8           Sample_Hello!_imp____wgetmainargs = Since we know my intended function is ‘main’ so I searched for it. The highlighted one is our main function. Then unassembled the function using following command: 0:000> uf Sample_Hello!wmain Sample_Hello!wmain

This part of the discussion will revolve more towards inside of Windows OS. I bet you’ll love the way it has been designed and evolved. Issues might be there while using the OS but it’s a matter of debate whether application has been designed the way windows expect etc. This is not the space for that debate. Also, it’s is a not aim to teach anyone about windows but some facts and figure and little bit stack analysis and more. This is the first attempt from my side to do little bit debugging (I’m not an experienced debugger without source code) for user mode. Note: Mark’s (Mark Russionovich, widely popular for his work in Windows Internals) work always been inspiring for me. Let’s start the journey : In this series target environment is x86. In this series, I’d like to cover: 1.        Thread Environment Block: It’s a data structure that stores info about the currently running thread of a process. 2.        How it looks and what’s the significance of it? Le