Jump-start your project by learning from devs who
write Windows drivers and file systems every day.
Take an OSR seminar!

OSR is Hiring! Click here to find out more.

Windows Internals & Software Drivers Lab, Santa Clara, CA 5-9 August, 2013
Kernel Debugging & Crash Analysis for Windows Lab, Santa Clara, CA 9-13 September, 2013
Upcoming OSR Seminars:
Writing WDF Drivers for Windows Lab, Boston, MA 7-11 October, 2013
Developing File Systems for Windows, Seattle, WA 5-8 November, 2013

Go Back   OSR Online Lists > ntdev
link swapping IRP's MDLs
Welcome, Guest
You must login to post to this list
  Message 1 of 18  
16 Oct 12 20:08
ntdev member 133881
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
swapping IRP's MDLs
Hi all, Been implementing a filter driver, and I've been experiencing some issues with the FS buffer allocations. from what I'm seeing, it looks like NTFS is using a dummy page for some of the buffer (while reading the data coming back in the IRP buffers I'm getting memory corruptions). my Idea for a fix was to snatch the IRP, swap it's buffers and MDL with my own, read, copy and swap back. I keep getting BSOD, I looked thrue msdn documentation and the forum and for the life of me I can't figure out why.. Can it be related to a pageable memory access error ? if so why and how do I fix it ? Filled with hope I'm attaching the code and the output of windbg !analyze. Thanks, Keller static void AllocAndReplaceMdlInReq(request_t *pReq) { pReq = &pReq->platf_request; pReq->mdlSwitched = FALSE; pReq->p_system_mdl = pReq->p_io->MdlAddress; pReq->p_system_buff = pReq->p_io->UserBuffer; pReq->p_new_mdl = NULL; fc_PRINT_REQUEST_DATA(pReq,"fcWinAllocAndReplaceMdlInReq - start", __LINE__); TrNOISE(, "pReq->p_io->MdlAddress->buf=%p", MmGetSystemAddressForMdlSafe(pReq->p_system_mdl, NormalPagePriority)); buff_size = MmGetMdlByteCount(pReq->p_system_mdl); allignToPages(&buff_size); pBuf = ExAllocatePoolWithTag ( /* _In_ POOL_TYPE PoolType */ NonPagedPool , /* _In_ SIZE_T NumberOfBytes */ buff_size, /* _In_ ULONG Tag*/ FC_MALLOC_TAG_STRING ); if (pBuf == NULL) { TrERROR("Failed to allocate bufffer."); return; } pReq->p_new_mdl = IoAllocateMdl(pBuf, (u32_t)buff_size, FALSE, FALSE, NULL); if (pReq->p_new_mdl == NULL) { TrERROR("Failed to allocate MDL. freeing allocated buffer."); ExFreePoolWithTag(pBuf, FC_MALLOC_TAG_STRING); return; } MmBuildMdlForNonPagedPool(pReq->p_new_mdl); // swap MDLs if (SWAP_FILES){ TrNOISE("Swapping IPR MDL to fc located one."); pReq->p_io->MdlAddress = pReq->p_new_mdl; pReq->p_io->UserBuffer = MmGetSystemAddressForMdlSafe(pReq->p_new_mdl, HighPagePriority); } pReq->mdlSwitched = TRUE; } static void fcWinFreeAndRestoreMdlBuf(fc_request_t* pReq) { fc_platform_request_t *pReq; PVOID mdl_fc_buf; PVOID mdl_system_buf; // copy data from mdl_swapped_buf to mdl_orig_buf mdl_fc_buf = MmGetSystemAddressForMdlSafe(pReq->p_new_mdl, HighPagePriority); mdl_system_buf = MmGetSystemAddressForMdlSafe(pReq->p_system_mdl, HighPagePriority);//, NormalPagePriority); byteCount/*Length*/); RtlCopyMemory (mdl_system_buf , //Destination mdl_fc_buf, //Source MmGetMdlByteCount(pReq->p_system_mdl)/*Length*/); // Set the p_io mdl to the original one. pReq->p_io->MdlAddress = pReq->p_system_mdl; pReq->p_io->UserBuffer = pReq->p_system_buff; IoFreeMdl(pReq->p_new_mdl); ExFreePoolWithTag(mdl_fc_buf, fc_MALLOC_TAG_STRING); pReq->p_new_mdl = NULL; } 0: kd> !analyze -v ERROR: FindPlugIns 8007007b ERROR: Some plugins may not be available [8007007b] ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: fffffa82d9784f60, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80001616557, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: fffffa82d9784f60 CURRENT_IRQL: 2 FAULTING_IP: hal!HalBuildScatterGatherList+12b fffff800`01616557 498b09 mov rcx,qword ptr [r9] DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: explorer.exe TRAP_FRAME: fffff88006c4cab0 -- (.trap 0xfffff88006c4cab0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffffa8018d8c600 rbx=0000000000000000 rcx=0000000000000000 rdx=fffff98001c4a000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff800019d7b87 rsp=fffff88006c4cc40 rbp=0000000000000000 r8=000000000000000f r9=fffff88006c4cd00 r10=0000000000000000 r11=0000000000000001 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz ac po cy nt!CcMapData+0x117: Page 5d58f not present in the dump file. Type ".hh dbgerr004" for details fffff800`019d7b87 0fb602 movzx eax,byte ptr [rdx] ds:fffff980`01c4a000=?? Resetting default scope LAST_CONTROL_TRANSFER: from fffff800016dabe9 to fffff800016db640 STACK_TEXT: fffff880`06c4b658 fffff800`016dabe9 : 00000000`0000000a fffffa82`d9784f60 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx fffff880`06c4b660 fffff800`016d9860 : fffffa80`19725168 fffffa80`1972efa0 fffffa80`1972aff0 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff880`06c4b7a0 fffff800`01616557 : 00000000`00000001 fffff880`0195e10d 00000000`00000244 00000000`00000000 : nt!KiPageFault+0x260 fffff880`06c4b930 fffff880`0131bed1 : fffffa80`1948e010 fffffa80`18d44aa0 00000000`0000003c fffffa80`00000000 : hal!HalBuildScatterGatherList+0x12b fffff880`06c4b9a0 fffff880`0131baf7 : fffffa80`00000001 fffffa80`18d44aa0 00000000`00001000 fffffa80`19245b10 : storport!RaUnitStartIo+0x2e1 fffff880`06c4ba20 fffff880`0131b71d : fffffa80`1a17d000 fffff880`01339110 fffffa80`00000000 00000000`00000000 : storport!RaUnitScsiIrp+0x397 fffff880`06c4bae0 fffff880`01980cae : 00000000`00000000 00000000`00000001 fffffa80`196712f0 fffffa80`1935d501 : storport!RaDriverScsiIrp+0x5d fffff880`06c4bb20 fffff880`0197ec92 : fffffa80`1a926010 fffffa80`1a9a9e90 fffffa80`18d44aa0 fffff880`00000001 : EFfc!fc_platform_down_dispatch+0x74e [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 3989] fffff880`06c4bc30 fffff880`01965df4 : fffffa80`1a9a9e90 fffffa80`1a926010 fffffa80`18d44aa0 fffffa80`19f57c90 : EFfc!fc_platform_dispatch_source_io+0x62 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 3196] fffff880`06c4bc60 fffff880`01967cf1 : fffffa80`1a9a9e90 fffff880`0198a110 fffffa80`00000b36 fffff880`0197d870 : EFfc!fc_dispatch_source_io+0x184 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc.c @ 2056] fffff880`06c4bcb0 fffff880`019690f6 : fffffa80`1a9a9e90 fffff880`0198a2b0 fffff880`00000d67 fffffa80`196a1050 : EFfc!fc_process_io+0x381 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc.c @ 2995] fffff880`06c4bd20 fffff880`0197f600 : fffffa80`1a926010 fffffa80`18d44aa0 fffff880`0198c000 fffffa80`18d44aa0 : EFfc!fc_top_dispatch+0xac6 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc.c @ 3467] fffff880`06c4be50 fffff880`0197cc95 : fffffa80`1935d5c0 fffffa80`18d44aa0 fffffa80`19736880 00000000`00000000 : EFfc!fc_platform_top_dispatch+0x1a0 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 3462] fffff880`06c4beb0 fffff880`0197a728 : fffffa80`1935d470 fffffa80`18d44aa0 00000000`00000000 fffff800`016e7e6a : EFfc!fcWinFiDOIo+0x45 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 2387] fffff880`06c4bef0 fffff880`019b5445 : fffffa80`1935d470 fffffa80`18d44aa0 fffffa80`196712f0 00000000`c010a000 : EFfc!fcWinDispatch+0x98 [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 1142] fffff880`06c4bf40 fffff880`019b5975 : fffffa80`19573010 fffffa80`1935d470 00000000`00101000 fffff880`00000001 : CLASSPNP!ServiceTransferRequest+0x355 fffff880`06c4bfe0 fffff880`011e10af : fffffa80`1a94f190 fffff880`06c4c2f0 fffffa80`1a94f410 fffffa80`1a85e110 : CLASSPNP!ClassReadWrite+0xd5 fffff880`06c4c030 fffff880`00d9718c : fffffa80`193a5610 fffffa80`1a94f190 fffffa80`1a94f190 00000000`00000001 : partmgr!PmGlobalDispatch+0x9f fffff880`06c4c060 fffff880`018ef1cf : fffff880`06c4c2f0 fffffa80`1a94f190 fffffa80`1957d190 fffff800`0172731c : volmgr!VmReadWrite+0x11c fffff880`06c4c0a0 fffff880`0144939a : fffff880`06c4c218 00000000`00000000 fffffa80`1966c010 00000000`00001000 : volsnap!VolSnapReadFilter+0x5f fffff880`06c4c0d0 fffff800`016e8078 : fffff880`06c4c2a0 fffff880`01447d06 fffff880`06c4c5f0 fffffa80`1966c010 : Ntfs!NtfsStorageDriverCallout+0x16 fffff880`06c4c100 fffff880`01448f09 : fffff880`01449384 00000000`0000b000 fffffa80`00001000 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xd8 fffff880`06c4c1e0 fffff880`014483d6 : fffffa80`1966bd80 00000000`00000000 fffffa80`1966c010 fffffa80`1a9a7d0c : Ntfs!NtfsMultipleAsync+0xa9 fffff880`06c4c250 fffff880`01440fc6 : fffff880`06c4c5f0 fffffa80`1a94f190 fffffa80`1966c010 00000000`000000c4 : Ntfs!NtfsNonCachedIo+0x216 fffff880`06c4c420 fffff880`01442a68 : fffff880`06c4c5f0 fffffa80`1a94f190 fffff880`06c4c701 fffffa80`1aa01201 : Ntfs!NtfsCommonRead+0x7a6 fffff880`06c4c5c0 fffff880`013896af : fffffa80`19668240 fffffa80`1a94f190 fffffa80`1aa01200 fffffa80`1a94f190 : Ntfs!NtfsFsdRead+0x1b8 fffff880`06c4c7d0 fffff800`01703635 : fffffa80`1a94f1b0 fffffa80`19670cb0 fffffa80`19dd42f0 fffff800`0184de80 : fltmgr!FltpDispatch+0x9f fffff880`06c4c830 fffff800`01703109 : 00000000`00000000 00000000`00000000 fffffa80`19dd4230 00000000`00000000 : nt!IoPageRead+0x255 fffff880`06c4c8c0 fffff800`016e99b9 : 00000000`00000000 00000000`00000000 ffffffff`ffffffff 00000000`00000000 : nt!MiIssueHardFault+0x255 fffff880`06c4c950 fffff800`016d976e : 00000000`00000000 fffff980`01c4a000 00000000`00000000 00000000`0000000e : nt!MmAccessFault+0x1399 fffff880`06c4cab0 fffff800`019d7b87 : fffff980`00000001 00000000`0000a000 fffff880`06c4cd08 fffff880`06c4cd00 : nt!KiPageFault+0x16e fffff880`06c4cc40 fffff880`014e31e2 : fffffa80`00036000 fffffa80`18d8c600 fffffa80`209ceb00 fffff800`0000000e : nt!CcMapData+0x117 fffff880`06c4cd00 fffff880`014ded5c : fffffa80`1aa0cba0 fffffa80`1966a180 fffff8a0`05933018 00000000`00000801 : Ntfs!NtfsReadMftRecord+0xb2 fffff880`06c4cdb0 fffff880`014bf19a : fffff8a0`05933014 fffff8a0`05933000 fffffa80`19f4fc60 00000000`00000000 : Ntfs!NtfsLookupInFileRecord+0x6c fffff880`06c4ce40 fffff880`014b7e8f : fffffa80`1aa0cba0 fffff8a0`05933010 fffffa80`1aa0cb00 fffff8a0`05933010 : Ntfs!NtfsUpdateFcbInfoFromDisk+0xaa fffff880`06c4cf90 fffff880`014dc179 : fffff880`06c4d530 fffffa80`19f4fc60 fffffa80`1aa0cba0 00000000`00000000 : Ntfs!NtfsOpenFile+0x2cf fffff880`06c4d180 fffff880`01444a3d : fffffa80`1aa0cba0 fffffa80`19f4fc60 fffff880`06c4d530 fffff800`01806300 : Ntfs!NtfsCommonCreate+0xc49 fffff880`06c4d360 fffff800`016e8078 : fffff880`06c4d4a0 fffff8a0`005db040 ffff0201`06000000 a0798000`00000010 : Ntfs!NtfsCommonCreateCallout+0x1d fffff880`06c4d390 fffff880`014451bf : fffff880`01444a20 fffff880`01444020 fffffa80`19f4fc00 fffff880`014e5f00 : nt!KeExpandKernelStackAndCalloutEx+0xd8 fffff880`06c4d470 fffff880`014de99c : 00000000`00000000 00000000`00000000 fffffa80`1aa087c8 fffffa80`19f4fc60 : Ntfs!NtfsCommonCreateOnNewStack+0x4f fffff880`06c4d4d0 fffff880`013aa0b6 : fffffa80`1966a030 fffffa80`19f4fc60 fffff8a0`00020000 6d4e6f49`1aa9ef20 : Ntfs!NtfsFsdCreate+0x1ac fffff880`06c4d680 fffff800`019d9495 : 00000000`00000005 fffffa80`1aa087c8 fffffa80`1a02bb10 fffffa80`1aa9efb8 : fltmgr!FltpCreate+0xa6 fffff880`06c4d730 fffff800`019d5d38 : fffffa80`193a54c0 fffff800`00000000 fffffa80`1aa08610 fffffa80`00000001 : nt!IopParseDevice+0x5a5 fffff880`06c4d8c0 fffff800`019d6f56 : 00000000`00000000 fffffa80`1aa08610 fffffa80`1a163200 fffffa80`18dcb600 : nt!ObpLookupObjectName+0x588 fffff880`06c4d9b0 fffff800`019d885c : fffffa80`1aa9eef0 00000000`00000000 fffffa80`1a083901 fffffa80`1aa9eee0 : nt!ObOpenObjectByName+0x306 fffff880`06c4da80 fffff800`019c4134 : 00000000`060d8f68 fffff8a0`00020080 00000000`0393eca0 00000000`0393ec90 : nt!IopCreateFile+0x2bc fffff880`06c4db20 fffff800`016da8d3 : fffffa80`1a163290 00000000`00000001 fffffa80`1aa012a0 fffff800`019d2a34 : nt!NtOpenFile+0x58 fffff880`06c4dbb0 00000000`76e1164a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`0393ec58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x76e1164a STACK_COMMAND: kb FOLLOWUP_IP: EFfc!fc_platform_down_dispatch+74e [c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c @ 3989] fffff880`01980cae 4881c400010000 add rsp,100h FAULTING_SOURCE_LINE: c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c FAULTING_SOURCE_FILE: c:\work\desktop_r15\project\l\dev\fc\driver\cache\fc_win.c FAULTING_SOURCE_LINE_NUMBER: 3989 FAULTING_SOURCE_CODE: 3985: IoCallDriver(pDevExt->common.pLowerDO, pIrp); 3986: /* Never touch either Irp or Pirp from here */ 3987: 3988: return; > 3989: } 3990: 3991: 3992: /** 3993: * Allocate/free read/write Irp 3994: */ SYMBOL_STACK_INDEX: 7 SYMBOL_NAME: EFfc!fc_platform_down_dispatch+74e FOLLOWUP_NAME: MachineOwner MODULE_NAME: EFfc IMAGE_NAME: EFfc.sys DEBUG_FLR_IMAGE_TIMESTAMP: 507ddfc7 FAILURE_BUCKET_ID: X64_0xA_EFfc!fc_platform_down_dispatch+74e BUCKET_ID: X64_0xA_EFfc!fc_platform_down_dispatch+74e Followup: MachineOwner ---------
  Message 2 of 18  
16 Oct 12 20:30
Joseph M. Newcomer
xxxxxx@flounder.com
Join Date: 20 Nov 2008
Posts To This List: 1886
Re: swapping IRP's MDLs
There is no such thing as "a BSOD". There is always a specific error code, and frequently a specific instruction, and always a stack backtrace. This is what !analyze -v tells you. Without this information, the only known way to analyze the problem is using psychic vibrations, and the PTP (Psychic Transfer Protocol) is not installed on my machine. You have not said what IRQL this happens at, or, if you are using paged memory, why you have neglected to lock it down if it is being accessed from elevated IRQL. But in the absence of a meaningful description, this is just guesswork. joe > Hi all, > > Been implementing a filter driver, and I've been experiencing some issues > with > the FS buffer allocations. > from what I'm seeing, it looks like NTFS is using a dummy page for some of > the > buffer > (while reading the data coming back in the IRP buffers I'm getting memory > corruptions). <...excess quoted lines suppressed...>
  Message 3 of 18  
17 Oct 12 02:42
ntdev member 133881
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
RE: swapping IRP's MDLs
Hi Joe, in the original text I attached you'll find the callstack, IRQL_NOT_LESS_OR_EQUAL is the error code, DISPATCH_LEVEL is the IRQL I'm operation in, and in the code you may see that I'm using NonPagedPool as the flag for the pool type in ExAllocatePoolWithTag. (as for the PTP, I'lll try to set up a server for that once I'm done with the current prob..) with that clarified, is there any more information I should post here for you to assist ? any Ideas as for what I'm doing wrong ?
  Message 4 of 18  
17 Oct 12 08:52
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 3926
List Moderator
RE: swapping IRP's MDLs
I'm seeing a page fault in the paging path in that crash stack... anybody else? Peter OSR
  Message 5 of 18  
17 Oct 12 13:04
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 1835
RE: swapping IRP's MDLs
The crash occurs in BuildScatterGatherList. To diagnose that, you need to print the allocated buffer address, and also see what Driver Verifier options are enabled.
  Message 6 of 18  
18 Oct 12 00:20
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8628
Re: swapping IRP's MDLs
> The crash occurs in BuildScatterGatherList Which is probably due to malformed MDL -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 7 of 18  
18 Oct 12 11:05
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 1835
RE: swapping IRP's MDLs
Oh, so you're filtering above Storport. Sorry, it's not that simple. Because the original buffer's MDL and address is set to the SRB by CLASSPNP. You're fudging the Irp->MdlAddress, and the BuildSGL function gets royally confused.
  Message 8 of 18  
20 Oct 12 15:24
ntdev member 133881
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
RE: swapping IRP's MDLs
Hey guys, first thanks all for the replies. so I made some changes, and adjusted the code to coply with msdn's http://msdn.microsoft.com/en-us/library/windows/hardware/gg463193.aspx however, still failing in the BuildScatterGatherList while accessing memory which is 32 bit later than most initialized data. any suggestions ? can it be related to the stack location on some level ? as I understand it, buffer replacement for a filter driver should be pretty straight forward.. code is attached. thank, K fc_platform_request_t *pPReq; PMDL fc_mdl = 0; pPReq->n_system_buffer_size = MmGetMdlByteCount(pReq->p_io->MdlAddress); pPReq->p_system_buffer = MmGetMdlVirtualAddress(pReq->p_io->MdlAddress); pPReq->p_fc_buffer = ExAllocatePoolWithTag ( //allocate the buffer itself /* _In_ POOL_TYPE PoolType */ NonPagedPool , /* _In_ SIZE_T NumberOfBytes */ pPReq->n_system_buffer_size, /* _In_ ULONG Tag*/ fc_MALLOC_TAG_STRING ); if (pPReq->p_fc_buffer == NULL) { TrERROR("Failed to allocate bufffer."); return; } /* allocates a memory descriptor list * the allocated MDL is associated with the specified IRP's MDL list */ fc_mdl = IoAllocateMdl( pPReq->p_fc_buffer, /*_In_opt_ PVOID VirtualAddress,*/ (u32_t)pPReq->n_system_buffer_size, /*_In_ ULONG Length,*/ FALSE, /*_In_ BOOLEAN SecondaryBuffer,*/ FALSE, /*_In_ BOOLEAN ChargeQuota,*/ pReq->p_io /*_Inout_opt_ PIRP Irp*/); if (fc_mdl == NULL) { TrERROR("Failed allocate new MDL. releasing allocated buffer."); ExFreePoolWithTag(pPReq->p_fc_buffer, fc_MALLOC_TAG_STRING); return; } //Update the MDL to describe the underlying physical pages MmBuildMdlForNonPagedPool(fc_mdl);
  Message 9 of 18  
20 Oct 12 18:31
Alex Grig
xxxxxx@broadcom.com
Join Date: 14 Apr 2008
Posts To This List: 1835
RE: swapping IRP's MDLs
OK. Let me repeat that again: You're sitting at the level where the relevant information is already put into the SRB. It's not enough to simply modify the IRP.
  Message 10 of 18  
20 Oct 12 20:21
Calvin Guan
xxxxxx@gradovec.com
Join Date: 11 Oct 2009
Posts To This List: 378
Re: swapping IRP's MDLs
This IRP is not that IRP. You really need to pay attention to what Alex said. And I would add, stop messing the IRP at your level. Instead, look for the SRB in the IRP, read the classpnp (is it still part of DDK?)source code with regard to how a FS RW irp is sliced/translated to SRB encoded into the same IRP and submitted to the port driver. Calvin p.s. MSFT open source the classpnp is a lifesaver for those who need to debug pesky issues in storport/scsiprt drivers. I hope they also open source storport.sys, ndis.sys and even better, tcpip.sys, netio.sys too. On Sat, Oct 20, 2012 at 12:23 PM, <xxxxx@gmail.com> wrote: > Hey guys, > > first thanks all for the replies. > > so I made some changes, and adjusted the code to coply with msdn's > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463193.aspx > however, still failing in the BuildScatterGatherList while accessing > memory which is 32 bit later than most initialized data. > > any suggestions ? <...excess quoted lines suppressed...> --
  Message 11 of 18  
21 Oct 12 10:52
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 3926
List Moderator
RE: swapping IRP's MDLs
<quote> I hope they also open source storport.sys, ndis.sys and even better, tcpip.sys, netio.sys too. </quote> We have hoped, wished, even PRAYED for this for many years. ESPECIALLY StorPort -- Having this source readily available would make life SOOO much easier for storage developers. So, while I continue to beg for the release of the StorPort source code, I don't hold out much hope that this will happen. I suspect that the intent of keeping the source private is that they want us to be writing to the PUBLISHED interface as its documented, and not rely on details of the interface implementation. I get that. But the docs on StorPort are, ah, "a bit sketchy" -- they have always been. And there are inherent complexities in the storage stack that make the task of writing truly truly comprehensive documentation for StorPort very difficult. I, for one, would prefer an approach that said "Here's the StorPort code, but we're not going to be constrained by the fact that the source is available for reference... so if you rely on some aspect that's not documented and we break your stuff in the field, too bad." Of course, THAT's easier said than done, right? Break the driver running the main storage adapter on 5 million desktops, because some otherwise well-meaning dev used the source code and relied on an undocumented detail of implementation that gets changed in a Service Pack? Who do you think would get the phone calls... So, like I said... I'm not exactly holding my breath waiting for StorPort source code to appear in the WDK. While our prayers have yet to be answered, we continue to hope... Peter OSR
  Message 12 of 18  
21 Oct 12 13:33
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 3492
RE: swapping IRP's MDLs
> I suspect that the intent of keeping the source private is that they want us to be writing to the > PUBLISHED interface as its documented, and not rely on details of the interface implementation. Well, this is just a complete BS, and I bet you know it perfectly well..... The fact of having sources open has absolutely nothing to do with encouraging use of undocumented interfaces that are not supposed to be used directly. For example, look at ndis.h - there are quite a few structures that are exposed to developers, but only a tiny fraction of these structures is meant to be used by driver writers. Look at DEVICE_OBJECT - it has some fields (like NextDevice) that are not supposed to be accessed by programmers. MSFT does not seem to be particularly worried by the above, does it - after all, it is driver writer who puts himself/herself/itself at risk by accessing fields that are not supposed to be accessed. There are multiple reasons for this. First of all, by opening your source one does not take an obligation to never apply changes to it, right - unless these changes break the "official" interfaces MSFT is still free to apply as many changes as it wants. Therefore, one fine day you may find your product shattered to pieces if you rely upon these features. Furthermore, even if we make a bold assumption that these interfaces will never change, you cannot ensure proper synchronization with the legitimate resource owner, which does not add to your product's overall stability either. Although such potential instability may occasionally be tolerated by, say, AV writer, it is hardly acceptable for someone who writes drivers for storage devices. Therefore, I guess the true reason is much more trivial, and is generally known by the standard name of "unfair market practice" - it allows MSFT to selectively apply "everyone is equal, but some are significantly more equal than others" principle. The problem is that someone who actually knows what makes a given library tick is automatically at the advantage to those who don't and have to rely only upon brief and often inconsistent documentation. There is no need to use any undocumented interfaces in order to be at the SIGNIFICANT advantage to an "average Joe" who has no source of info other than MSDN - a simple theoretical knowledge will suffice.... > So, while I continue to beg for the release of the StorPort source code, I don't hold out much hope > that this will happen. You are not trying to say that you have no access to these sources, are you..... Anton Bassov
  Message 13 of 18  
21 Oct 12 13:50
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 3926
List Moderator
RE: swapping IRP's MDLs
<quote> Therefore, one fine day you may find your product shattered to pieces if you rely upon these features </quote> And here we were doing so well, too, you and I. You REALLY don't get it, do you. If YOU wrote a driver that relies on the internal behaviors of StorPort, and an OEM ships that, and it's in use on MILLIONS of desktops... and the behavior of StorPort changes in a way that breaks MILLIONS of desk tops... YOU'RE not going to get millions phone calls from angry customers. Microsoft is. People will say "Windows Update broke my system... Microsoft sucks." I'm telling you this is often the thinking internally and it, not the desire to engage in some cabalistic activity, is what dictates many behaviors you obviously do not understand. <quote> You are not trying to say that you have no access to these sources, are you..... </quote> I don't think I even implied anything of the sort. As I think you already know, I spend a great deal of my time/effort trying to be a positive advocate for the community. It has nothing to do with what I have or OSR has or you have. It has to do with what's good for the community. Peter OSR
  Message 14 of 18  
21 Oct 12 14:59
Calvin Guan
xxxxxx@gradovec.com
Join Date: 11 Oct 2009
Posts To This List: 378
Re: swapping IRP's MDLs
<quote> and an OEM ships that, and it's in use on MILLIONS of desktops... and the behavior of StorPort changes in a way that breaks MILLIONS of desk tops. </quote> I guess it won't take long to for the GM of chipmaker to get a nasty phone call from the OEM demanding x,y and z. Well thank God, it never happened to me:). My approach is be creative as much as possible while debugging; actively explore system internal behaviors, write them down on paper before I forget. Don't hesitate to make use of any undocumented facts to setup a theory or construct a proof or counter proof. While comes to code implementation, in particular the contracting part, just be conservative, forget about all internals discovered. Just as USAF fighter pilots, if it is not on the thick book, you are not allowed to do it --- as opposed to Navy fighter pilots, if that small book doesn't say you can't do it, you can do whatever it takes to get the job done, come back and land on the flight deck of the carrier safely. Make no mistake, they are both the world's best fighter pilots. Calvin --
  Message 15 of 18  
21 Oct 12 15:17
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 3492
RE: swapping IRP's MDLs
> You REALLY don't get it, do you. If YOU wrote a driver that relies on the internal behaviors of StorPort, > and an OEM ships that, and it's in use on MILLIONS of desktops... and the behavior of StorPort changes > in a way that breaks MILLIONS of desk tops... YOU'RE not going to get millions phone calls from > angry customers. Microsoft is. People will say "Windows Update broke my system... Microsoft sucks." Sorry, Peter, but, indeed, I REALLY don't get it....... If behavior of Storport changes, say, in a next version of the OS, what on Earth does it have to do with OEM version of the OS that is already installed on user's computer??? In case if OEM ships the new version of the OS with the old version of a driver this is already 100% OEM's fault. Users are not going to call MSFT - they will just go to the shop and say "this shitty PC/laptop that you sold me does not work - I want my money back", and this will happen right after the very first attempt to boot the machine..... Therefore, I really don't get it at all..... > I'm telling you this is often the thinking internally and it, not the desire to engage in > some cabalistic activity, is what dictates many behaviors you obviously do not understand. You know, if some "strange" move comes from someone with the history of a market abuse as extensive as that of MSFT, one somehow gets suspicious on the spot, don't you think..... > As I think you already know, I spend a great deal of my time/effort trying to be a positive advocate > for the community. It has nothing to do with what I have or OSR has or you have. It has to do with > what's good for the community. Fair enough - I am really sorry if I sounded somewhat sarcastic... Anton Bassov
  Message 16 of 18  
21 Oct 12 15:18
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 650
RE: swapping IRP's MDLs
Having worked on mini-computer OS'es that published the source on fiche I've seen this happen. In fact I suffered it happening, when two of the largest customers found that some fields of various packets used by a lot of system calls for parameters while marked reserved were never checked for any value. Their clever programmers started using those fields for their own use, only to scream when we started checking for zero with a new OS release, since we planned to start using them in the next major release. In the end the minor release slipped 3 months while we ripped out all the checks, and the next major OS slipped almost a year to create a secondary set of calls that used same packets (i.e. something like ReadFile and ReadFileEx except the parameters were the same request block!). Even worse a distributed OS was stillborn by upper management when customers who started depending on undocumented behavior demanded we keep these unique undocumented quirks. The president caved in both cases to the pressure from the customers, and in this latter case did not even check with engineering to discover he was throwing out 60 man years of development by his decision. This type of shit happens all the time. I personally would much prefer that Microsoft put the resources into making the doc's better than all the effort through their legal to make sources available. Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "xxxxx@osr.com" <xxxxx@osr.com> wrote in message news:183634@ntdev: > <quote> > Therefore, > one fine day you may find your product shattered to pieces if you rely upon > these features > </quote> > > And here we were doing so well, too, you and I. > > You REALLY don't get it, do you. If YOU wrote a driver that relies on the internal behaviors of StorPort, and an OEM ships that, and it's in use on MILLIONS of desktops... and the behavior of StorPort changes in a way that breaks MILLIONS of desk tops... YOU'RE not going to get millions phone calls from angry customers. Microsoft is. People will say "Windows Update broke my system... Microsoft sucks." > <...excess quoted lines suppressed...>
  Message 17 of 18  
21 Oct 12 19:17
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 3926
List Moderator
RE: swapping IRP's MDLs
<quote> I really don't get it </quote> Sad... And we were making such good progress, too. You really do need to get out more. Hang with a different group of folks, perhaps. Try to see things from a different perspective, through someone else's eyes. Maybe you should get a job at Microsoft. WinSE is hiring, and I can tell you from personal knowledge they're a smart group of folks who get their hands into all sorts of interesting places in the OS. Peter OSR
  Message 18 of 18  
21 Oct 12 21:22
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 3492
RE: swapping IRP's MDLs
> You really do need to get out more. Hang with a different group of folks, perhaps. Try to see things > from a different perspective, through someone else's eyes. Do you mean I should start looking at the world through the eyes of Windows aficinados, MSFT marketing department et al??? > Maybe you should get a job at Microsoft. Are you joking or what??? > WinSE is hiring, and I can tell you from personal knowledge they're a smart group of folks who > get their hands into all sorts of interesting places in the OS. Well, the term "smart" may be pretty subjective.... The person who is "smart"( in my understanding of things, of course) and MSFT are just two opposites that will never get together. Why? Simply because a smart engineer requires some degree of freedom of technical self-expression, and this is NOT what he will get in a company that is driven by its marketing department. No matter how good the idea is, they are going to screw it up in the name of "backwards compatibility", "interoperability" or whatever the term they use. I don't want to make blank statements. Therefore, let's look at some practical examples. For example, look at the Transactional NTFS. The idea of transactional file system in itself is just brilliant - so brilliant that, AFAIK, it does not yet have any commercial-grade implementation under any OS in so far, despite some research projects being done with variable degree of success. However, look at the way they've actually done it. I just could not believe my own eyes when I read MSDN article on the subject - instead of writing data to some location on the disk and simply flipping pointers upon the commit or marking space as free upon the rollback they actually overwrite data...... and do so after having copied it to some other location. Look at the cumbersome API that it it exposes. No wonder that their implementation found zero demand among the developers, so that MSFT is about to deprecate it. I have a weird feeling that it happened not because their engineers were so incredibly dumb that they decided to physically move on-disk user data - it seems to me that, in the name of "backwards compatibility" or for similar reasons, they were just requested to make the whole thing inter-operate with the older NTFS layers in such a way that introducing optimizations that allow to minimize the frequency of disk access already did not make sense at this stag e..... No, don't get me wrong - I clearly realize how complex a project like that is. Developing a FS like that is quite a serious challenge even under the open-source and easily extensible system like Linux, because the entire logic of such file system's operations is totally different from the one of the "regular" FS, which is true for both handling requests on the upper edge and submitting the ones to the block layer on the lower one. Therefore, you need to develop special layers that will allow you to handle these tasks, and make them co-exist with VFS on the upper edge and block IO subsystem on the lower one. I hope by now you already realize that the very mentioning of "backwards compatibility" simply kills such a project on the spot..... Anton Bassov
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 02:05.

Contact Us - Osr Online Homepage - Top

Copyright ©2012, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license