NTFS Access Faults

[Ashish_Goyal]

Hi,
We are getting Double Fault error due to Stack Overflow. We see following
calls in stack :

18 ba0203cc 8082645c nt!IoPageRead+0x109

84 ba020450 8084790e nt!MiDispatchFault+0xd74

5c ba0204ac 80836c4c nt!MmAccessFault+0x64a

0 ba0204ac 80936fad nt!KiTrap0E+0xdc

c8 ba020574 f7279f6e nt!CcMapData+0x8c

20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b

74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86

38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a

38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37

110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd

1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d

1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe

ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66

1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113

14 ba020de0 f731ed28 nt!IofCallDriver+0x45

2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152

14 ba020e20 f731eb25 nt!IofCallDriver+0x45

24 ba020e44 f731ecf5
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f

14 ba020e90 b9c357f1 nt!IofCallDriver+0x45

34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91

70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa

14 ba020f48 80824b6f nt!IofCallDriver+0x45

18 ba020f60 8082645c nt!IoPageRead+0x109

84 ba020fe4 8084790e nt!MiDispatchFault+0xd74

5c ba021040 80836c4c nt!MmAccessFault+0x64a

0 ba021040 80936fad nt!KiTrap0E+0xdc

c8 ba021108 f7279f6e nt!CcMapData+0x8c

20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b

30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f

174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62

fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0

208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1

170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf

14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have
another system with exactly same configuration (Software and hardware) in
cluster where this problem does not occur.

Question:

1. Is there some way we can make NTFS data structure memory resident so that
   they do not incur page fault.

2. What is the best way to resolve these error - this is causing recursion
   in our driver and hence crash.

Thanks

Ashish

[OSR_Community_User]

>1) Is there some way we can make NTFS data structure memory resident so that they do not incur

page fault.

Doubts.

Too many filter drivers cause exactly this.

You have DxSpy (legacy) and 2 FltMgr frames on the stack.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Scott_Noone_OSR]

This part of your stack looks OK, you need to increase the stack depth so
that we can see the rest of the stack:

.kframes 1000

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Ashish Goyal” wrote in message
news:xxxxx@ntfsd…
Hi,
We are getting Double Fault error due to Stack Overflow. We see following
calls in stack :
18 ba0203cc 8082645c nt!IoPageRead+0x109
84 ba020450 8084790e nt!MiDispatchFault+0xd74
5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
0 ba0204ac 80936fad nt!KiTrap0E+0xdc
c8 ba020574 f7279f6e nt!CcMapData+0x8c
20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
14 ba020de0 f731ed28 nt!IofCallDriver+0x45
2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
14 ba020e20 f731eb25 nt!IofCallDriver+0x45
24 ba020e44 f731ecf5
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
14 ba020f48 80824b6f nt!IofCallDriver+0x45
18 ba020f60 8082645c nt!IoPageRead+0x109
84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
5c ba021040 80836c4c nt!MmAccessFault+0x64a
0 ba021040 80936fad nt!KiTrap0E+0xdc
c8 ba021108 f7279f6e nt!CcMapData+0x8c
20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have
another system with exactly same configuration (Software and hardware) in
cluster where this problem does not occur.
Question:
1) Is there some way we can make NTFS data structure memory resident so that
they do not incur page fault.
2) What is the best way to resolve these error - this is causing recursion
in our driver and hence crash.

Thanks
Ashish

[Gary_Little-3]

First, making “the NTFS data structure” resident such that it does not cause
a page fault sounds more like a knee-jerk reaction to a problem that is
really NOT understood. By your own admission this problem occurs on only ONE
system. It seems that the most judicious use of your time would be to find
out what is different between system A that works and system B that doesn’t
work. There is something different and that is what you need to discover,
because there lies the permanent fix, and most likely less time expenditure.

Have you stepped into your driver? Does it happen when your driver/software
is not loaded? Have you run !analyze -v when your driver crashes? What is
your driver doing that is causing the problem and what have you done to find
it?

Gary G. Little

H (952) 223-1349

C (952) 454-4629

xxxxx@comcast.net

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashish Goyal
Sent: Wednesday, August 25, 2010 5:35 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] NTFS Access Faults

Hi,

We are getting Double Fault error due to Stack Overflow. We see following
calls in stack :

18 ba0203cc 8082645c nt!IoPageRead+0x109

84 ba020450 8084790e nt!MiDispatchFault+0xd74

5c ba0204ac 80836c4c nt!MmAccessFault+0x64a

0 ba0204ac 80936fad nt!KiTrap0E+0xdc

c8 ba020574 f7279f6e nt!CcMapData+0x8c

20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b

74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86

38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a

38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37

110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd

1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d

1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe

ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66

1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113

14 ba020de0 f731ed28 nt!IofCallDriver+0x45

2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152

14 ba020e20 f731eb25 nt!IofCallDriver+0x45

24 ba020e44 f731ecf5
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f

14 ba020e90 b9c357f1 nt!IofCallDriver+0x45

34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91

70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa

14 ba020f48 80824b6f nt!IofCallDriver+0x45

18 ba020f60 8082645c nt!IoPageRead+0x109

84 ba020fe4 8084790e nt!MiDispatchFault+0xd74

5c ba021040 80836c4c nt!MmAccessFault+0x64a

0 ba021040 80936fad nt!KiTrap0E+0xdc

c8 ba021108 f7279f6e nt!CcMapData+0x8c

20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b

30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f

174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62

fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0

208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1

170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf

14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have
another system with exactly same configuration (Software and hardware) in
cluster where this problem does not occur.

Question:

1. Is there some way we can make NTFS data structure memory resident so that
   they do not incur page fault.

2. What is the best way to resolve these error - this is causing recursion
   in our driver and hence crash.

Thanks

Ashish

— NTFSD is sponsored by OSR For our schedule of debugging and file system
seminars (including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars To unsubscribe, visit the List Server section of
OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Aditya_Shrivastava]

>>1) Is there some way we can make NTFS data structure memory resident so that they do not incur page fault.

I don’t think so, considering that will contradict with basic theory behind NTFS(extendability). A MFT record will always be of some fix size and there can be several use cases when its necessary to make it non-resident. This is not a solution for any of the problem.

Its a double fault (stack overflow), which is telling you that some driver code is not re-entrant. If the crash does not come without your driver, you should look into your code instead of fixing NTFS.

[Ashish_Goyal]

Hi,
Thanks for Reply…

The problem we are facing is recursion (Our Driver is DxSpy). Since the two
System are virtual Images, so I am not sure why there was difference. Also,
MFT is I guess access to often so I thought this data structure might be
resident at all time. So was the question.

Thanks
Ashish

On Wed, Aug 25, 2010 at 4:05 PM, Ashish Goyal wrote:

> Hi,
> We are getting Double Fault error due to Stack Overflow. We see following
> calls in stack :
>
> 18 ba0203cc 8082645c nt!IoPageRead+0x109
>
> 84 ba020450 8084790e nt!MiDispatchFault+0xd74
>
> 5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
>
> 0 ba0204ac 80936fad nt!KiTrap0E+0xdc
>
> c8 ba020574 f7279f6e nt!CcMapData+0x8c
>
> 20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
>
> 74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
>
> 38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
>
> 38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
>
> 110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
>
> 1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
>
> 1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
>
> ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
>
> 1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
>
> 14 ba020de0 f731ed28 nt!IofCallDriver+0x45
>
> 2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
>
> 14 ba020e20 f731eb25 nt!IofCallDriver+0x45
>
> 24 ba020e44 f731ecf5
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
>
> 38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
>
> 14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
>
> 34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
>
> 70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
>
> 14 ba020f48 80824b6f nt!IofCallDriver+0x45
>
> 18 ba020f60 8082645c nt!IoPageRead+0x109
>
> 84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
>
> 5c ba021040 80836c4c nt!MmAccessFault+0x64a
>
> 0 ba021040 80936fad nt!KiTrap0E+0xdc
>
> c8 ba021108 f7279f6e nt!CcMapData+0x8c
>
> 20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
>
> 30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
>
> 174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
>
> fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
>
> 208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
>
> 170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
>
> 14 ba021754 f731eb25 nt!IofCallDriver+0x45
>
>
> So there are calls for reading NTFS data structures. Problem is we have
> another system with exactly same configuration (Software and hardware) in
> cluster where this problem does not occur.
>
> Question:
>
> 1) Is there some way we can make NTFS data structure memory resident so
> that they do not incur page fault.
>
> 2) What is the best way to resolve these error - this is causing recursion
> in our driver and hence crash.
>
>
> Thanks
>
> Ashish
>

[Scott_Noone_OSR]

You still haven’t shown the full stack.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Ashish Goyal” wrote in message
news:xxxxx@ntfsd…
Hi,
Thanks for Reply…

The problem we are facing is recursion (Our Driver is DxSpy). Since the two
System are virtual Images, so I am not sure why there was difference. Also,
MFT is I guess access to often so I thought this data structure might be
resident at all time. So was the question.

Thanks
Ashish

On Wed, Aug 25, 2010 at 4:05 PM, Ashish Goyal
wrote:

Hi,
We are getting Double Fault error due to Stack Overflow. We see following
calls in stack :
18 ba0203cc 8082645c nt!IoPageRead+0x109
84 ba020450 8084790e nt!MiDispatchFault+0xd74
5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
0 ba0204ac 80936fad nt!KiTrap0E+0xdc
c8 ba020574 f7279f6e nt!CcMapData+0x8c
20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
14 ba020de0 f731ed28 nt!IofCallDriver+0x45
2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
14 ba020e20 f731eb25 nt!IofCallDriver+0x45
24 ba020e44 f731ecf5
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
14 ba020f48 80824b6f nt!IofCallDriver+0x45
18 ba020f60 8082645c nt!IoPageRead+0x109
84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
5c ba021040 80836c4c nt!MmAccessFault+0x64a
0 ba021040 80936fad nt!KiTrap0E+0xdc
c8 ba021108 f7279f6e nt!CcMapData+0x8c
20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have
another system with exactly same configuration (Software and hardware) in
cluster where this problem does not occur.
Question:
1) Is there some way we can make NTFS data structure memory resident so that
they do not incur page fault.
2) What is the best way to resolve these error - this is causing recursion
in our driver and hence crash.

Thanks
Ashish

[Aditya_Shrivastava]

>> Also, MFT is I guess access to often so I thought this data structure might be resident at all time.

Oops, you meant resident in memory and not in MFT record. From your stack NtfsUpdateFileNameInIndex indicates that NTFS is probably changing/adding the file name inside a directory attributes, which will anyhow go to the mft file on disk sooner or later you can not avoid that.

I would again ask, does the system crash without ur driver if not you need to debug ur driver.

[Ashish_Goyal]

Hi Scott,
Sorry…I missed it…Here is the stack trace.

Adi : The crash happens due to recursion as you can see from stack below. So
the best option is to go for mini-filter which will take some time. That’s
why I was inquiring to see if anything can be done to prevent the page
faults related to MFT.

Thanks
Ash

00000000 8083991b 00000000 00000000 00000000 nt!KiTrap08+0x75
b8d6c000 8083980a b8d6c040 88ab7858 f772f120 nt!SwapContext+0xf
b8d6c014 8083d5b1 88ab77e0 88ab7888 00000001 nt!KiSwapContext+0x26
b8d6c040 8083df9e 895d4780 00000000 877c5008 nt!KiSwapThread+0x2e5
b8d6c088 f722950e b8d6c1d8 00000000 00000000 nt!KeWaitForSingleObject+0x346
b8d6c23c 80840153 895d2020 877c5008 877c5008 Ntfs!NtfsFsdRead+0x22c
b8d6c250 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6c27c 80840153 895d5820 877c5008 877c5008 fltmgr!FltpDispatch+0x152
b8d6c290 f71187e6 00000000 89ed3d30 0cbfb000 nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be
wrong.
b8d6c2bc 80840153 895e8ac8 877c5008 894d5488
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6c2d0 b872f7f1 00000000 894d5488 0cbfb000 nt!IofCallDriver+0x45
b8d6c304 b872c93a 89015470 877c5008 0000094a DxSpy+0x127f1
b8d6c374 80840153 890153b8 877c5008 877c5008 DxSpy+0xf93a
b8d6c388 80824b6f 88b48f78 88ab77e0 88b48f68 nt!IofCallDriver+0x45
b8d6c3a0 8082645c 8969760e 88b48fa0 88b48f80 nt!IoPageRead+0x109
b8d6c424 8084790e 00000001 cf43b000 c033d0ec nt!MiDispatchFault+0xd74
b8d6c480 80836c4c 00000000 cf43b000 00000000 nt!MmAccessFault+0x64a
b8d6c480 80936f75 00000000 cf43b000 00000000 nt!KiTrap0E+0xdc
b8d6c548 f7260f2d 89697628 b8d6c578 00000400 nt!CcMapData+0x8c
b8d6c568 f725e494 b8d6cc68 895d4780 0cbfb000 Ntfs!NtfsMapStream+0x4b
b8d6c5dc f7260df0 b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadMftRecord+0x86
b8d6c614 f7252b3a b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadFileRecord+0x7a
b8d6c66c f7252c75 b8d6cc68 e13d6c60 000000a0
Ntfs!NtfsLookupExternalAttribute+0x293
b8d6c6ac f721f8a8 b8d6cc68 e13d6c60 d3282490
Ntfs!NtfsLookupInFileRecord+0x14c
b8d6c7bc f7220674 b8d6cc68 e14f9c70 00000115 Ntfs!NtfsLookupAllocation+0xdd
b8d6c98c f722082c b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsPrepareBuffers+0x25d
b8d6cb68 f7221156 b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsNonCachedIo+0x1ee
b8d6cc54 f7221079 b8d6cc68 86c28a28 00000001 Ntfs!NtfsCommonRead+0xaf5
b8d6ce00 80840153 895d2020 86c28a28 86c28a28 Ntfs!NtfsFsdRead+0x113
b8d6ce14 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6ce40 80840153 895d5820 86c28a28 86c28a28 fltmgr!FltpDispatch+0x152
b8d6ce54 f71187e6 00000000 89ed3d30 00115000 nt!IofCallDriver+0x45
b8d6ce80 80840153 895e8ac8 86c28a28 894d5488
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6ce94 b872f7f1 00000000 894d5488 00115000 nt!IofCallDriver+0x45
b8d6cec8 b872c93a 89015470 86c28a28 0000094a DxSpy+0x127f1
b8d6cf38 80840153 890153b8 86c28a28 86c28a28 DxSpy+0xf93a
b8d6cf4c 80824b6f 89d71e40 88ab77e0 89d71e30 nt!IofCallDriver+0x45
b8d6cf64 8082645c 8970940e 89d71e68 89d71e48 nt!IoPageRead+0x109
b8d6cfe8 8084790e 00000001 dea55000 c037a954 nt!MiDispatchFault+0xd74
b8d6d044 80836c4c 00000000 dea55000 00000000 nt!MmAccessFault+0x64a
b8d6d044 80936f75 00000000 dea55000 00000000 nt!KiTrap0E+0xdc
b8d6d10c f7260f2d 897094b8 b8d6d13c 00001000 nt!CcMapData+0x8c
b8d6d12c f72639d5 88562988 e14f9c70 00115000 Ntfs!NtfsMapStream+0x4b
b8d6d15c f7264050 88562988 0000000c 00000115 Ntfs!ReadIndexBuffer+0x8f
b8d6d18c f724f746 88562988 e59456a0 b8d6d2f4 Ntfs!FindFirstIndexEntry+0x196
b8d6d294 f724f83c 88562988 e14f9c70 b8d6d2f4 Ntfs!NtOfsFindRecord+0xa4
b8d6d2fc f724f95e 88562988 895d2100 000035e1
Ntfs!MapSecurityIdToSecurityDescriptorHeaderUnsafe+0x32
b8d6d34c f724cd97 88562988 895d2100 000035e1
Ntfs!NtfsCacheSharedSecurityBySecurityId+0x9e
b8d6d3c4 f724cdae 88562988 e4290c60 02000000
Ntfs!NtfsLoadSecurityDescriptor+0x2d
b8d6d460 f726abc2 88562988 e4290c60 e686bc60 Ntfs!NtfsAccessCheck+0x37
b8d6d494 f725bafd 88562988 877c5470 e4290f28 Ntfs!NtfsCheckExistingFile+0x9a
b8d6d4c4 f725bb51 88562988 877c5298 877c5470 Ntfs!NtfsOpenExistingAttr+0x30
b8d6d5a0 f726ae19 88562988 877c5298 877c5470
Ntfs!NtfsOpenAttributeInExistingFile+0x1b3
b8d6d684 f72618b9 88562988 877c5298 877c5470
Ntfs!NtfsOpenExistingPrefixFcb+0x25e
b8d6d7d0 f7261ef8 88562988 877c5298 b8d6d810 Ntfs!NtfsCommonCreate+0x127e
b8d6d8d4 80840153 895d2020 877c5298 877c5298 Ntfs!NtfsFsdCreate+0x17d
b8d6d8e8 f7304b25 00000000 877c5298 877c5494 nt!IofCallDriver+0x45
b8d6d90c f73125de b8d6d92c 895d5820 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8d6d948 80840153 895d5820 877c5298 b8d6da90 fltmgr!FltpCreate+0x26a
b8d6d95c f711818d e3da83d4 b8d6da90 f712dfb8 nt!IofCallDriver+0x45
b8d6d99c f70f9ca0 b8d6da90 89e99008 877c5298
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6d9bc f70fb0f6 b8d6da90 877c54b8 89e99008 mfehidk+0x7ca0
b8d6d9e0 f70fbf1c b8d6da90 877c54b8 87e4ad68 mfehidk+0x90f6
b8d6da78 f7118791 55555555 87e4ad68 89ed3d30 mfehidk+0x9f1c
b8d6daa8 80840153 895e8ac8 877c5298 877c5298
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6dabc 8092e87e b8d6dc64 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6dba4 8092c3ea 89f594c8 00000000 874311b8 nt!IopParseDevice+0xa35
b8d6dc24 8092d80d 00000000 b8d6dc64 00000040 nt!ObpLookupObjectName+0x5b0
b8d6dc78 8092c6cd 00000000 00000000 56298800 nt!ObOpenObjectByName+0xea
b8d6dcf4 808c1058 b8d6deb8 00100008 b8d6dd88 nt!IopCreateFile+0x447
b8d6dd3c b87291ad b8d6deb8 00100008 b8d6dd88
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6ddc4 b8721422 86f46280 895e8ac8 b8d6deb0 DxSpy+0xc1ad
b8d6df18 b8722edb b873aaf8 895e8ac8 87bdd4f0 DxSpy+0x4422
b8d6e07c b872ca3a 895e8ac8 87bdd4f0 86f46280 DxSpy+0x5edb
b8d6e0e8 b8730fe2 890153b8 87bdd4f0 00000000 DxSpy+0xfa3a
b8d6e140 80840153 890153b8 87bdd4f0 87bdd4f0 DxSpy+0x13fe2
b8d6e154 8092e87e b8d6e2fc 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6e23c 8092c3ea 89f594c8 00000000 89d4fd20 nt!IopParseDevice+0xa35
b8d6e2bc 8092d80d 00000000 b8d6e2fc 00000240 nt!ObpLookupObjectName+0x5b0
b8d6e310 8092c6cd 00000000 00000000 fdfd2800 nt!ObOpenObjectByName+0xea
b8d6e38c 808c1058 874008b0 00100000 b8d6e424 nt!IopCreateFile+0x447
b8d6e3d4 f7318a94 874008b0 00100000 b8d6e424
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6e47c f73191bb 00000000 00000000 00000049
fltmgr!FltpExpandFilePathWorker+0x118
b8d6e494 f73192ff 87400868 886dcce4 87400868 fltmgr!FltpExpandFilePath+0x19
b8d6e4b0 f731998b 87400868 886dcce4 000000fe
fltmgr!FltpGetNormalizedFileNameWorker+0x5f
b8d6e4c8 f73170bc 87400868 886dcce4 87400868
fltmgr!FltpGetNormalizedFileName+0x19
b8d6e4e0 f7306610 808a5180 00000001 00000000
fltmgr!FltpCreateFileNameInformation+0x84
b8d6e4fc f7306774 88ed8278 886dccec 00000000
fltmgr!HandleStreamListNotSupported+0xfc
b8d6e528 f7306c94 c00000bb 00000000 886dccec
fltmgr!FltpGetFileNameInformation+0xe8
b8d6e550 f72d98f2 006dccec 00000101 b8d6e594
fltmgr!FltGetFileNameInformation+0x114
b8d6e5c0 f73024ca 886dccec b8d6e5e0 b8d6e5fc
datascrn!DataScreenPreCreate+0x98
b8d6e620 f7303f2a 00d6e664 886dcc90 86b2df94
fltmgr!FltpPerformPreCallbacks+0x2d4
b8d6e634 f73120ad b8d6e664 f7310540 00000000
fltmgr!FltpPassThroughInternal+0x32
b8d6e64c f73125cc b8d6e664 00000000 86b2dd98 fltmgr!FltpCreateInternal+0x63
b8d6e680 80840153 895d5820 86b2dd98 b8d6e7a8 fltmgr!FltpCreate+0x258
b8d6e694 f711818d 884e3244 884e31e8 b8d6e7a8 nt!IofCallDriver+0x45
b8d6e6d4 f70fb17c b8d6e7a8 86b2dfb8 89e99008
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6e6f8 f70fbf1c b8d6e7a8 00000002 87536bd0 mfehidk+0x917c
b8d6e790 f7118791 cccccccc 86b2dfdc 89ed3d30 mfehidk+0x9f1c
b8d6e7c0 80840153 895e8ac8 86b2dd98 86b2e000
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6e7d4 b872f7f1 86b2dfdc 86b2e000 871c8f08 nt!IofCallDriver+0x45
b8d6e808 b872cbd1 89015470 86b2dd98 00000b1e DxSpy+0x127f1
b8d6e87c b8730fe2 890153b8 86b2dd98 00000000 DxSpy+0xfbd1
b8d6e8d4 80840153 890153b8 86b2dd98 86b2dd98 DxSpy+0x13fe2
b8d6e8e8 8092e87e 8907b900 871c8f08 00000000 nt!IofCallDriver+0x45
b8d6e9d0 8093ab00 890153b8 00000000 87560168 nt!IopParseDevice+0xa35
b8d6ea08 8092c13e 8907b900 00000000 87560168 nt!IopParseFile+0x46
b8d6ea88 8092d80d 80000ab8 b8d6eac8 00000040 nt!ObpLookupObjectName+0x11f
b8d6eadc 8092c6cd 00000000 00000000 ab770000 nt!ObOpenObjectByName+0xea
b8d6eb58 80931d92 b8d6ecc8 0002019f b8d6ec90 nt!IopCreateFile+0x447
b8d6ebb4 b90473f3 b8d6ecc8 0002019f b8d6ec90 nt!IoCreateFile+0xa3
b8d6ec24 b90492e7 89376130 b8d6ecc8 0002019f srv!SrvIoCreateFile+0x36d
b8d6ecf0 b9047b68 86f5d7e0 e40033a0 0002019f srv!SrvNtCreateFile+0x5e0
b8d6ed78 b9026e87 89376138 893db260 b903e6c7 srv!SrvSmbNtCreateAndX+0x15c
b8d6ed84 b903e6c7 00000000 88ab77e0 00000000 srv!SrvProcessSmb+0xb7
b8d6edac 809208bb 003db260 00000000 00000000 srv!WorkerThread+0x138
b8d6eddc 8083fe9f b903e602 893db260 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

On Thu, Aug 26, 2010 at 5:18 PM, Scott Noone wrote:

> You still haven’t shown the full stack.
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Ashish Goyal” wrote in message
> news:xxxxx@ntfsd…
>
> Hi,
> Thanks for Reply…
>
>
> The problem we are facing is recursion (Our Driver is DxSpy). Since the two
> System are virtual Images, so I am not sure why there was difference. Also,
> MFT is I guess access to often so I thought this data structure might be
> resident at all time. So was the question.
>
>
> Thanks
> Ashish
>
>
> On Wed, Aug 25, 2010 at 4:05 PM, Ashish Goyal
> wrote:
>
> Hi,
> We are getting Double Fault error due to Stack Overflow. We see following
> calls in stack :
> 18 ba0203cc 8082645c nt!IoPageRead+0x109
> 84 ba020450 8084790e nt!MiDispatchFault+0xd74
> 5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
> 0 ba0204ac 80936fad nt!KiTrap0E+0xdc
> c8 ba020574 f7279f6e nt!CcMapData+0x8c
> 20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
> 74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
> 38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
> 38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
> 110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
> 1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
> 1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
> ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
> 1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
> 14 ba020de0 f731ed28 nt!IofCallDriver+0x45
> 2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
> 14 ba020e20 f731eb25 nt!IofCallDriver+0x45
> 24 ba020e44 f731ecf5
> fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
> 38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
> 14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
> 34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
> 70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
> 14 ba020f48 80824b6f nt!IofCallDriver+0x45
> 18 ba020f60 8082645c nt!IoPageRead+0x109
> 84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
> 5c ba021040 80836c4c nt!MmAccessFault+0x64a
> 0 ba021040 80936fad nt!KiTrap0E+0xdc
> c8 ba021108 f7279f6e nt!CcMapData+0x8c
> 20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
> 30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
> 174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
> fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
> 208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
> 170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
> 14 ba021754 f731eb25 nt!IofCallDriver+0x45
>
>
> So there are calls for reading NTFS data structures. Problem is we have
> another system with exactly same configuration (Software and hardware) in
> cluster where this problem does not occur.
> Question:
> 1) Is there some way we can make NTFS data structure memory resident so
> that they do not incur page fault.
> 2) What is the best way to resolve these error - this is causing recursion
> in our driver and hence crash.
>
>
> Thanks
> Ashish
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

[rod_widdowson]

I’m still not sure that I see anything completely odd about this stack. The pagefault when loading the mapping information isn’t something I’ve seen before, but if NTFS want to do that it’ fine by me.

My only concern is if DxSpy had changed a paging read into a non paging one (I know that mfehidk wouldn’t). But that would be DxSpy’s problem which wouldn’t be fixable by changing Ntfs’s behavior.

Rod

“Ashish Goyal” wrote in message news:xxxxx@ntfsd…
Hi Scott,
Sorry…I missed it…Here is the stack trace.

Adi : The crash happens due to recursion as you can see from stack below. So the best option is to go for mini-filter which will take some time. That’s why I was inquiring to see if anything can be done to prevent the page faults related to MFT.

Thanks
Ash

00000000 8083991b 00000000 00000000 00000000 nt!KiTrap08+0x75
b8d6c000 8083980a b8d6c040 88ab7858 f772f120 nt!SwapContext+0xf
b8d6c014 8083d5b1 88ab77e0 88ab7888 00000001 nt!KiSwapContext+0x26
b8d6c040 8083df9e 895d4780 00000000 877c5008 nt!KiSwapThread+0x2e5
b8d6c088 f722950e b8d6c1d8 00000000 00000000 nt!KeWaitForSingleObject+0x346
b8d6c23c 80840153 895d2020 877c5008 877c5008 Ntfs!NtfsFsdRead+0x22c
b8d6c250 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6c27c 80840153 895d5820 877c5008 877c5008 fltmgr!FltpDispatch+0x152
b8d6c290 f71187e6 00000000 89ed3d30 0cbfb000 nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
b8d6c2bc 80840153 895e8ac8 877c5008 894d5488 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6c2d0 b872f7f1 00000000 894d5488 0cbfb000 nt!IofCallDriver+0x45
b8d6c304 b872c93a 89015470 877c5008 0000094a DxSpy+0x127f1
b8d6c374 80840153 890153b8 877c5008 877c5008 DxSpy+0xf93a
b8d6c388 80824b6f 88b48f78 88ab77e0 88b48f68 nt!IofCallDriver+0x45
b8d6c3a0 8082645c 8969760e 88b48fa0 88b48f80 nt!IoPageRead+0x109
b8d6c424 8084790e 00000001 cf43b000 c033d0ec nt!MiDispatchFault+0xd74
b8d6c480 80836c4c 00000000 cf43b000 00000000 nt!MmAccessFault+0x64a
b8d6c480 80936f75 00000000 cf43b000 00000000 nt!KiTrap0E+0xdc
b8d6c548 f7260f2d 89697628 b8d6c578 00000400 nt!CcMapData+0x8c
b8d6c568 f725e494 b8d6cc68 895d4780 0cbfb000 Ntfs!NtfsMapStream+0x4b
b8d6c5dc f7260df0 b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadMftRecord+0x86
b8d6c614 f7252b3a b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadFileRecord+0x7a
b8d6c66c f7252c75 b8d6cc68 e13d6c60 000000a0 Ntfs!NtfsLookupExternalAttribute+0x293
b8d6c6ac f721f8a8 b8d6cc68 e13d6c60 d3282490 Ntfs!NtfsLookupInFileRecord+0x14c
b8d6c7bc f7220674 b8d6cc68 e14f9c70 00000115 Ntfs!NtfsLookupAllocation+0xdd
b8d6c98c f722082c b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsPrepareBuffers+0x25d
b8d6cb68 f7221156 b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsNonCachedIo+0x1ee
b8d6cc54 f7221079 b8d6cc68 86c28a28 00000001 Ntfs!NtfsCommonRead+0xaf5
b8d6ce00 80840153 895d2020 86c28a28 86c28a28 Ntfs!NtfsFsdRead+0x113
b8d6ce14 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6ce40 80840153 895d5820 86c28a28 86c28a28 fltmgr!FltpDispatch+0x152
b8d6ce54 f71187e6 00000000 89ed3d30 00115000 nt!IofCallDriver+0x45
b8d6ce80 80840153 895e8ac8 86c28a28 894d5488 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6ce94 b872f7f1 00000000 894d5488 00115000 nt!IofCallDriver+0x45
b8d6cec8 b872c93a 89015470 86c28a28 0000094a DxSpy+0x127f1
b8d6cf38 80840153 890153b8 86c28a28 86c28a28 DxSpy+0xf93a
b8d6cf4c 80824b6f 89d71e40 88ab77e0 89d71e30 nt!IofCallDriver+0x45
b8d6cf64 8082645c 8970940e 89d71e68 89d71e48 nt!IoPageRead+0x109
b8d6cfe8 8084790e 00000001 dea55000 c037a954 nt!MiDispatchFault+0xd74
b8d6d044 80836c4c 00000000 dea55000 00000000 nt!MmAccessFault+0x64a
b8d6d044 80936f75 00000000 dea55000 00000000 nt!KiTrap0E+0xdc
b8d6d10c f7260f2d 897094b8 b8d6d13c 00001000 nt!CcMapData+0x8c
b8d6d12c f72639d5 88562988 e14f9c70 00115000 Ntfs!NtfsMapStream+0x4b
b8d6d15c f7264050 88562988 0000000c 00000115 Ntfs!ReadIndexBuffer+0x8f
b8d6d18c f724f746 88562988 e59456a0 b8d6d2f4 Ntfs!FindFirstIndexEntry+0x196
b8d6d294 f724f83c 88562988 e14f9c70 b8d6d2f4 Ntfs!NtOfsFindRecord+0xa4
b8d6d2fc f724f95e 88562988 895d2100 000035e1 Ntfs!MapSecurityIdToSecurityDescriptorHeaderUnsafe+0x32
b8d6d34c f724cd97 88562988 895d2100 000035e1 Ntfs!NtfsCacheSharedSecurityBySecurityId+0x9e
b8d6d3c4 f724cdae 88562988 e4290c60 02000000 Ntfs!NtfsLoadSecurityDescriptor+0x2d
b8d6d460 f726abc2 88562988 e4290c60 e686bc60 Ntfs!NtfsAccessCheck+0x37
b8d6d494 f725bafd 88562988 877c5470 e4290f28 Ntfs!NtfsCheckExistingFile+0x9a
b8d6d4c4 f725bb51 88562988 877c5298 877c5470 Ntfs!NtfsOpenExistingAttr+0x30
b8d6d5a0 f726ae19 88562988 877c5298 877c5470 Ntfs!NtfsOpenAttributeInExistingFile+0x1b3
b8d6d684 f72618b9 88562988 877c5298 877c5470 Ntfs!NtfsOpenExistingPrefixFcb+0x25e
b8d6d7d0 f7261ef8 88562988 877c5298 b8d6d810 Ntfs!NtfsCommonCreate+0x127e
b8d6d8d4 80840153 895d2020 877c5298 877c5298 Ntfs!NtfsFsdCreate+0x17d
b8d6d8e8 f7304b25 00000000 877c5298 877c5494 nt!IofCallDriver+0x45
b8d6d90c f73125de b8d6d92c 895d5820 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8d6d948 80840153 895d5820 877c5298 b8d6da90 fltmgr!FltpCreate+0x26a
b8d6d95c f711818d e3da83d4 b8d6da90 f712dfb8 nt!IofCallDriver+0x45
b8d6d99c f70f9ca0 b8d6da90 89e99008 877c5298 mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6d9bc f70fb0f6 b8d6da90 877c54b8 89e99008 mfehidk+0x7ca0
b8d6d9e0 f70fbf1c b8d6da90 877c54b8 87e4ad68 mfehidk+0x90f6
b8d6da78 f7118791 55555555 87e4ad68 89ed3d30 mfehidk+0x9f1c
b8d6daa8 80840153 895e8ac8 877c5298 877c5298 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6dabc 8092e87e b8d6dc64 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6dba4 8092c3ea 89f594c8 00000000 874311b8 nt!IopParseDevice+0xa35
b8d6dc24 8092d80d 00000000 b8d6dc64 00000040 nt!ObpLookupObjectName+0x5b0
b8d6dc78 8092c6cd 00000000 00000000 56298800 nt!ObOpenObjectByName+0xea
b8d6dcf4 808c1058 b8d6deb8 00100008 b8d6dd88 nt!IopCreateFile+0x447
b8d6dd3c b87291ad b8d6deb8 00100008 b8d6dd88 nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6ddc4 b8721422 86f46280 895e8ac8 b8d6deb0 DxSpy+0xc1ad
b8d6df18 b8722edb b873aaf8 895e8ac8 87bdd4f0 DxSpy+0x4422
b8d6e07c b872ca3a 895e8ac8 87bdd4f0 86f46280 DxSpy+0x5edb
b8d6e0e8 b8730fe2 890153b8 87bdd4f0 00000000 DxSpy+0xfa3a
b8d6e140 80840153 890153b8 87bdd4f0 87bdd4f0 DxSpy+0x13fe2
b8d6e154 8092e87e b8d6e2fc 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6e23c 8092c3ea 89f594c8 00000000 89d4fd20 nt!IopParseDevice+0xa35
b8d6e2bc 8092d80d 00000000 b8d6e2fc 00000240 nt!ObpLookupObjectName+0x5b0
b8d6e310 8092c6cd 00000000 00000000 fdfd2800 nt!ObOpenObjectByName+0xea
b8d6e38c 808c1058 874008b0 00100000 b8d6e424 nt!IopCreateFile+0x447
b8d6e3d4 f7318a94 874008b0 00100000 b8d6e424 nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6e47c f73191bb 00000000 00000000 00000049 fltmgr!FltpExpandFilePathWorker+0x118
b8d6e494 f73192ff 87400868 886dcce4 87400868 fltmgr!FltpExpandFilePath+0x19
b8d6e4b0 f731998b 87400868 886dcce4 000000fe fltmgr!FltpGetNormalizedFileNameWorker+0x5f
b8d6e4c8 f73170bc 87400868 886dcce4 87400868 fltmgr!FltpGetNormalizedFileName+0x19
b8d6e4e0 f7306610 808a5180 00000001 00000000 fltmgr!FltpCreateFileNameInformation+0x84
b8d6e4fc f7306774 88ed8278 886dccec 00000000 fltmgr!HandleStreamListNotSupported+0xfc
b8d6e528 f7306c94 c00000bb 00000000 886dccec fltmgr!FltpGetFileNameInformation+0xe8
b8d6e550 f72d98f2 006dccec 00000101 b8d6e594 fltmgr!FltGetFileNameInformation+0x114
b8d6e5c0 f73024ca 886dccec b8d6e5e0 b8d6e5fc datascrn!DataScreenPreCreate+0x98
b8d6e620 f7303f2a 00d6e664 886dcc90 86b2df94 fltmgr!FltpPerformPreCallbacks+0x2d4
b8d6e634 f73120ad b8d6e664 f7310540 00000000 fltmgr!FltpPassThroughInternal+0x32
b8d6e64c f73125cc b8d6e664 00000000 86b2dd98 fltmgr!FltpCreateInternal+0x63
b8d6e680 80840153 895d5820 86b2dd98 b8d6e7a8 fltmgr!FltpCreate+0x258
b8d6e694 f711818d 884e3244 884e31e8 b8d6e7a8 nt!IofCallDriver+0x45
b8d6e6d4 f70fb17c b8d6e7a8 86b2dfb8 89e99008 mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6e6f8 f70fbf1c b8d6e7a8 00000002 87536bd0 mfehidk+0x917c
b8d6e790 f7118791 cccccccc 86b2dfdc 89ed3d30 mfehidk+0x9f1c
b8d6e7c0 80840153 895e8ac8 86b2dd98 86b2e000 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6e7d4 b872f7f1 86b2dfdc 86b2e000 871c8f08 nt!IofCallDriver+0x45
b8d6e808 b872cbd1 89015470 86b2dd98 00000b1e DxSpy+0x127f1
b8d6e87c b8730fe2 890153b8 86b2dd98 00000000 DxSpy+0xfbd1
b8d6e8d4 80840153 890153b8 86b2dd98 86b2dd98 DxSpy+0x13fe2
b8d6e8e8 8092e87e 8907b900 871c8f08 00000000 nt!IofCallDriver+0x45
b8d6e9d0 8093ab00 890153b8 00000000 87560168 nt!IopParseDevice+0xa35
b8d6ea08 8092c13e 8907b900 00000000 87560168 nt!IopParseFile+0x46
b8d6ea88 8092d80d 80000ab8 b8d6eac8 00000040 nt!ObpLookupObjectName+0x11f
b8d6eadc 8092c6cd 00000000 00000000 ab770000 nt!ObOpenObjectByName+0xea
b8d6eb58 80931d92 b8d6ecc8 0002019f b8d6ec90 nt!IopCreateFile+0x447
b8d6ebb4 b90473f3 b8d6ecc8 0002019f b8d6ec90 nt!IoCreateFile+0xa3
b8d6ec24 b90492e7 89376130 b8d6ecc8 0002019f srv!SrvIoCreateFile+0x36d
b8d6ecf0 b9047b68 86f5d7e0 e40033a0 0002019f srv!SrvNtCreateFile+0x5e0
b8d6ed78 b9026e87 89376138 893db260 b903e6c7 srv!SrvSmbNtCreateAndX+0x15c
b8d6ed84 b903e6c7 00000000 88ab77e0 00000000 srv!SrvProcessSmb+0xb7
b8d6edac 809208bb 003db260 00000000 00000000 srv!WorkerThread+0x138
b8d6eddc 8083fe9f b903e602 893db260 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

On Thu, Aug 26, 2010 at 5:18 PM, Scott Noone wrote:

You still haven’t shown the full stack.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Ashish Goyal” wrote in message news:xxxxx@ntfsd…

Hi,
Thanks for Reply…

The problem we are facing is recursion (Our Driver is DxSpy). Since the two System are virtual Images, so I am not sure why there was difference. Also, MFT is I guess access to often so I thought this data structure might be resident at all time. So was the question.

Thanks
Ashish

On Wed, Aug 25, 2010 at 4:05 PM, Ashish Goyal wrote:

Hi,
We are getting Double Fault error due to Stack Overflow. We see following calls in stack :
18 ba0203cc 8082645c nt!IoPageRead+0x109
84 ba020450 8084790e nt!MiDispatchFault+0xd74
5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
0 ba0204ac 80936fad nt!KiTrap0E+0xdc
c8 ba020574 f7279f6e nt!CcMapData+0x8c
20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
14 ba020de0 f731ed28 nt!IofCallDriver+0x45
2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
14 ba020e20 f731eb25 nt!IofCallDriver+0x45
24 ba020e44 f731ecf5 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
14 ba020f48 80824b6f nt!IofCallDriver+0x45
18 ba020f60 8082645c nt!IoPageRead+0x109
84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
5c ba021040 80836c4c nt!MmAccessFault+0x64a
0 ba021040 80936fad nt!KiTrap0E+0xdc
c8 ba021108 f7279f6e nt!CcMapData+0x8c
20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have another system with exactly same configuration (Software and hardware) in cluster where this problem does not occur.
Question:
1) Is there some way we can make NTFS data structure memory resident so that they do not incur page fault.
2) What is the best way to resolve these error - this is causing recursion in our driver and hence crash.

Thanks
Ashish

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

Have you said which O/S release this is? Surprising that no one has noticed
and posted this operation yet or expanded the stack (I.e.
KeExpandKernelStackAndCallout).

You really only have so many ways to fix this:

1. Post the operation yourself if you think stack space is getting low. For
   example, could you do your create from a worker thread? (You’re DxSpy,
   right?)

2. Go over your driver and get crazy minimizing your stack usage (for
   example, allocate your locals out of pool), The call chain in DxSpy that
   ultimately calls IoCreateFile is fairly greedy in stack space (900 bytes or
   so if I grabbed the right numbers) so I’d start there.

3. Have the customer uninstall one of the other filters

4. Switch to a mini-filter, which will ultimately consume much less stack
   space.

We had to do all sorts of horrible things in the FDDK to try to avoid stack
overflows, luckily things have gotten much better of the years (though you
probably won’t believe that right now :))

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Ashish Goyal” wrote in message
news:xxxxx@ntfsd…
Hi Scott,
Sorry…I missed it…Here is the stack trace.

Adi : The crash happens due to recursion as you can see from stack below. So
the best option is to go for mini-filter which will take some time. That’s
why I was inquiring to see if anything can be done to prevent the page
faults related to MFT.

Thanks
Ash

00000000 8083991b 00000000 00000000 00000000 nt!KiTrap08+0x75
b8d6c000 8083980a b8d6c040 88ab7858 f772f120 nt!SwapContext+0xf
b8d6c014 8083d5b1 88ab77e0 88ab7888 00000001 nt!KiSwapContext+0x26
b8d6c040 8083df9e 895d4780 00000000 877c5008 nt!KiSwapThread+0x2e5
b8d6c088 f722950e b8d6c1d8 00000000 00000000 nt!KeWaitForSingleObject+0x346
b8d6c23c 80840153 895d2020 877c5008 877c5008 Ntfs!NtfsFsdRead+0x22c
b8d6c250 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6c27c 80840153 895d5820 877c5008 877c5008 fltmgr!FltpDispatch+0x152
b8d6c290 f71187e6 00000000 89ed3d30 0cbfb000 nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be
wrong.
b8d6c2bc 80840153 895e8ac8 877c5008 894d5488
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6c2d0 b872f7f1 00000000 894d5488 0cbfb000 nt!IofCallDriver+0x45
b8d6c304 b872c93a 89015470 877c5008 0000094a DxSpy+0x127f1
b8d6c374 80840153 890153b8 877c5008 877c5008 DxSpy+0xf93a
b8d6c388 80824b6f 88b48f78 88ab77e0 88b48f68 nt!IofCallDriver+0x45
b8d6c3a0 8082645c 8969760e 88b48fa0 88b48f80 nt!IoPageRead+0x109
b8d6c424 8084790e 00000001 cf43b000 c033d0ec nt!MiDispatchFault+0xd74
b8d6c480 80836c4c 00000000 cf43b000 00000000 nt!MmAccessFault+0x64a
b8d6c480 80936f75 00000000 cf43b000 00000000 nt!KiTrap0E+0xdc
b8d6c548 f7260f2d 89697628 b8d6c578 00000400 nt!CcMapData+0x8c
b8d6c568 f725e494 b8d6cc68 895d4780 0cbfb000 Ntfs!NtfsMapStream+0x4b
b8d6c5dc f7260df0 b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadMftRecord+0x86
b8d6c614 f7252b3a b8d6cc68 895d2100 d91001e0 Ntfs!NtfsReadFileRecord+0x7a
b8d6c66c f7252c75 b8d6cc68 e13d6c60 000000a0
Ntfs!NtfsLookupExternalAttribute+0x293
b8d6c6ac f721f8a8 b8d6cc68 e13d6c60 d3282490
Ntfs!NtfsLookupInFileRecord+0x14c
b8d6c7bc f7220674 b8d6cc68 e14f9c70 00000115 Ntfs!NtfsLookupAllocation+0xdd
b8d6c98c f722082c b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsPrepareBuffers+0x25d
b8d6cb68 f7221156 b8d6cc68 86c28a28 e14f9c70 Ntfs!NtfsNonCachedIo+0x1ee
b8d6cc54 f7221079 b8d6cc68 86c28a28 00000001 Ntfs!NtfsCommonRead+0xaf5
b8d6ce00 80840153 895d2020 86c28a28 86c28a28 Ntfs!NtfsFsdRead+0x113
b8d6ce14 f7304d28 00000000 89e98480 895e8ac8 nt!IofCallDriver+0x45
b8d6ce40 80840153 895d5820 86c28a28 86c28a28 fltmgr!FltpDispatch+0x152
b8d6ce54 f71187e6 00000000 89ed3d30 00115000 nt!IofCallDriver+0x45
b8d6ce80 80840153 895e8ac8 86c28a28 894d5488
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0xd0
b8d6ce94 b872f7f1 00000000 894d5488 00115000 nt!IofCallDriver+0x45
b8d6cec8 b872c93a 89015470 86c28a28 0000094a DxSpy+0x127f1
b8d6cf38 80840153 890153b8 86c28a28 86c28a28 DxSpy+0xf93a
b8d6cf4c 80824b6f 89d71e40 88ab77e0 89d71e30 nt!IofCallDriver+0x45
b8d6cf64 8082645c 8970940e 89d71e68 89d71e48 nt!IoPageRead+0x109
b8d6cfe8 8084790e 00000001 dea55000 c037a954 nt!MiDispatchFault+0xd74
b8d6d044 80836c4c 00000000 dea55000 00000000 nt!MmAccessFault+0x64a
b8d6d044 80936f75 00000000 dea55000 00000000 nt!KiTrap0E+0xdc
b8d6d10c f7260f2d 897094b8 b8d6d13c 00001000 nt!CcMapData+0x8c
b8d6d12c f72639d5 88562988 e14f9c70 00115000 Ntfs!NtfsMapStream+0x4b
b8d6d15c f7264050 88562988 0000000c 00000115 Ntfs!ReadIndexBuffer+0x8f
b8d6d18c f724f746 88562988 e59456a0 b8d6d2f4 Ntfs!FindFirstIndexEntry+0x196
b8d6d294 f724f83c 88562988 e14f9c70 b8d6d2f4 Ntfs!NtOfsFindRecord+0xa4
b8d6d2fc f724f95e 88562988 895d2100 000035e1
Ntfs!MapSecurityIdToSecurityDescriptorHeaderUnsafe+0x32
b8d6d34c f724cd97 88562988 895d2100 000035e1
Ntfs!NtfsCacheSharedSecurityBySecurityId+0x9e
b8d6d3c4 f724cdae 88562988 e4290c60 02000000
Ntfs!NtfsLoadSecurityDescriptor+0x2d
b8d6d460 f726abc2 88562988 e4290c60 e686bc60 Ntfs!NtfsAccessCheck+0x37
b8d6d494 f725bafd 88562988 877c5470 e4290f28 Ntfs!NtfsCheckExistingFile+0x9a
b8d6d4c4 f725bb51 88562988 877c5298 877c5470 Ntfs!NtfsOpenExistingAttr+0x30
b8d6d5a0 f726ae19 88562988 877c5298 877c5470
Ntfs!NtfsOpenAttributeInExistingFile+0x1b3
b8d6d684 f72618b9 88562988 877c5298 877c5470
Ntfs!NtfsOpenExistingPrefixFcb+0x25e
b8d6d7d0 f7261ef8 88562988 877c5298 b8d6d810 Ntfs!NtfsCommonCreate+0x127e
b8d6d8d4 80840153 895d2020 877c5298 877c5298 Ntfs!NtfsFsdCreate+0x17d
b8d6d8e8 f7304b25 00000000 877c5298 877c5494 nt!IofCallDriver+0x45
b8d6d90c f73125de b8d6d92c 895d5820 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b8d6d948 80840153 895d5820 877c5298 b8d6da90 fltmgr!FltpCreate+0x26a
b8d6d95c f711818d e3da83d4 b8d6da90 f712dfb8 nt!IofCallDriver+0x45
b8d6d99c f70f9ca0 b8d6da90 89e99008 877c5298
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6d9bc f70fb0f6 b8d6da90 877c54b8 89e99008 mfehidk+0x7ca0
b8d6d9e0 f70fbf1c b8d6da90 877c54b8 87e4ad68 mfehidk+0x90f6
b8d6da78 f7118791 55555555 87e4ad68 89ed3d30 mfehidk+0x9f1c
b8d6daa8 80840153 895e8ac8 877c5298 877c5298
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6dabc 8092e87e b8d6dc64 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6dba4 8092c3ea 89f594c8 00000000 874311b8 nt!IopParseDevice+0xa35
b8d6dc24 8092d80d 00000000 b8d6dc64 00000040 nt!ObpLookupObjectName+0x5b0
b8d6dc78 8092c6cd 00000000 00000000 56298800 nt!ObOpenObjectByName+0xea
b8d6dcf4 808c1058 b8d6deb8 00100008 b8d6dd88 nt!IopCreateFile+0x447
b8d6dd3c b87291ad b8d6deb8 00100008 b8d6dd88
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6ddc4 b8721422 86f46280 895e8ac8 b8d6deb0 DxSpy+0xc1ad
b8d6df18 b8722edb b873aaf8 895e8ac8 87bdd4f0 DxSpy+0x4422
b8d6e07c b872ca3a 895e8ac8 87bdd4f0 86f46280 DxSpy+0x5edb
b8d6e0e8 b8730fe2 890153b8 87bdd4f0 00000000 DxSpy+0xfa3a
b8d6e140 80840153 890153b8 87bdd4f0 87bdd4f0 DxSpy+0x13fe2
b8d6e154 8092e87e b8d6e2fc 89f594b0 00000000 nt!IofCallDriver+0x45
b8d6e23c 8092c3ea 89f594c8 00000000 89d4fd20 nt!IopParseDevice+0xa35
b8d6e2bc 8092d80d 00000000 b8d6e2fc 00000240 nt!ObpLookupObjectName+0x5b0
b8d6e310 8092c6cd 00000000 00000000 fdfd2800 nt!ObOpenObjectByName+0xea
b8d6e38c 808c1058 874008b0 00100000 b8d6e424 nt!IopCreateFile+0x447
b8d6e3d4 f7318a94 874008b0 00100000 b8d6e424
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b8d6e47c f73191bb 00000000 00000000 00000049
fltmgr!FltpExpandFilePathWorker+0x118
b8d6e494 f73192ff 87400868 886dcce4 87400868 fltmgr!FltpExpandFilePath+0x19
b8d6e4b0 f731998b 87400868 886dcce4 000000fe
fltmgr!FltpGetNormalizedFileNameWorker+0x5f
b8d6e4c8 f73170bc 87400868 886dcce4 87400868
fltmgr!FltpGetNormalizedFileName+0x19
b8d6e4e0 f7306610 808a5180 00000001 00000000
fltmgr!FltpCreateFileNameInformation+0x84
b8d6e4fc f7306774 88ed8278 886dccec 00000000
fltmgr!HandleStreamListNotSupported+0xfc
b8d6e528 f7306c94 c00000bb 00000000 886dccec
fltmgr!FltpGetFileNameInformation+0xe8
b8d6e550 f72d98f2 006dccec 00000101 b8d6e594
fltmgr!FltGetFileNameInformation+0x114
b8d6e5c0 f73024ca 886dccec b8d6e5e0 b8d6e5fc
datascrn!DataScreenPreCreate+0x98
b8d6e620 f7303f2a 00d6e664 886dcc90 86b2df94
fltmgr!FltpPerformPreCallbacks+0x2d4
b8d6e634 f73120ad b8d6e664 f7310540 00000000
fltmgr!FltpPassThroughInternal+0x32
b8d6e64c f73125cc b8d6e664 00000000 86b2dd98 fltmgr!FltpCreateInternal+0x63
b8d6e680 80840153 895d5820 86b2dd98 b8d6e7a8 fltmgr!FltpCreate+0x258
b8d6e694 f711818d 884e3244 884e31e8 b8d6e7a8 nt!IofCallDriver+0x45
b8d6e6d4 f70fb17c b8d6e7a8 86b2dfb8 89e99008
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b8d6e6f8 f70fbf1c b8d6e7a8 00000002 87536bd0 mfehidk+0x917c
b8d6e790 f7118791 cccccccc 86b2dfdc 89ed3d30 mfehidk+0x9f1c
b8d6e7c0 80840153 895e8ac8 86b2dd98 86b2e000
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x7b
b8d6e7d4 b872f7f1 86b2dfdc 86b2e000 871c8f08 nt!IofCallDriver+0x45
b8d6e808 b872cbd1 89015470 86b2dd98 00000b1e DxSpy+0x127f1
b8d6e87c b8730fe2 890153b8 86b2dd98 00000000 DxSpy+0xfbd1
b8d6e8d4 80840153 890153b8 86b2dd98 86b2dd98 DxSpy+0x13fe2
b8d6e8e8 8092e87e 8907b900 871c8f08 00000000 nt!IofCallDriver+0x45
b8d6e9d0 8093ab00 890153b8 00000000 87560168 nt!IopParseDevice+0xa35
b8d6ea08 8092c13e 8907b900 00000000 87560168 nt!IopParseFile+0x46
b8d6ea88 8092d80d 80000ab8 b8d6eac8 00000040 nt!ObpLookupObjectName+0x11f
b8d6eadc 8092c6cd 00000000 00000000 ab770000 nt!ObOpenObjectByName+0xea
b8d6eb58 80931d92 b8d6ecc8 0002019f b8d6ec90 nt!IopCreateFile+0x447
b8d6ebb4 b90473f3 b8d6ecc8 0002019f b8d6ec90 nt!IoCreateFile+0xa3
b8d6ec24 b90492e7 89376130 b8d6ecc8 0002019f srv!SrvIoCreateFile+0x36d
b8d6ecf0 b9047b68 86f5d7e0 e40033a0 0002019f srv!SrvNtCreateFile+0x5e0
b8d6ed78 b9026e87 89376138 893db260 b903e6c7 srv!SrvSmbNtCreateAndX+0x15c
b8d6ed84 b903e6c7 00000000 88ab77e0 00000000 srv!SrvProcessSmb+0xb7
b8d6edac 809208bb 003db260 00000000 00000000 srv!WorkerThread+0x138
b8d6eddc 8083fe9f b903e602 893db260 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

On Thu, Aug 26, 2010 at 5:18 PM, Scott Noone wrote:

You still haven’t shown the full stack.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Ashish Goyal” wrote in message
news:xxxxx@ntfsd…

Hi,
Thanks for Reply…

The problem we are facing is recursion (Our Driver is DxSpy). Since the two
System are virtual Images, so I am not sure why there was difference. Also,
MFT is I guess access to often so I thought this data structure might be
resident at all time. So was the question.

Thanks
Ashish

On Wed, Aug 25, 2010 at 4:05 PM, Ashish Goyal
wrote:

Hi,
We are getting Double Fault error due to Stack Overflow. We see following
calls in stack :
18 ba0203cc 8082645c nt!IoPageRead+0x109
84 ba020450 8084790e nt!MiDispatchFault+0xd74
5c ba0204ac 80836c4c nt!MmAccessFault+0x64a
0 ba0204ac 80936fad nt!KiTrap0E+0xdc
c8 ba020574 f7279f6e nt!CcMapData+0x8c
20 ba020594 f72774d1 Ntfs!NtfsMapStream+0x4b
74 ba020608 f7279e31 Ntfs!NtfsReadMftRecord+0x86
38 ba020640 f7279fed Ntfs!NtfsReadFileRecord+0x7a
38 ba020678 f72388ac Ntfs!NtfsLookupInFileRecord+0x37
110 ba020788 f7239524 Ntfs!NtfsLookupAllocation+0xdd
1d0 ba020958 f72396dc Ntfs!NtfsPrepareBuffers+0x25d
1dc ba020b34 f723a043 Ntfs!NtfsNonCachedIo+0x1fe
ec ba020c20 f7239f4d Ntfs!NtfsCommonRead+0xb66
1ac ba020dcc 80840153 Ntfs!NtfsFsdRead+0x113
14 ba020de0 f731ed28 nt!IofCallDriver+0x45
2c ba020e0c 80840153 fltMgr!FltpDispatch+0x152
14 ba020e20 f731eb25 nt!IofCallDriver+0x45
24 ba020e44 f731ecf5
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
38 ba020e7c 80840153 fltMgr!FltpDispatch+0x11f
14 ba020e90 b9c357f1 nt!IofCallDriver+0x45
34 ba020ec4 b9c3293a DxSpy!CallAndRelease+0x91
70 ba020f34 80840153 DxSpy!FilterDispatch+0x2fa
14 ba020f48 80824b6f nt!IofCallDriver+0x45
18 ba020f60 8082645c nt!IoPageRead+0x109
84 ba020fe4 8084790e nt!MiDispatchFault+0xd74
5c ba021040 80836c4c nt!MmAccessFault+0x64a
0 ba021040 80936fad nt!KiTrap0E+0xdc
c8 ba021108 f7279f6e nt!CcMapData+0x8c
20 ba021128 f727ca1a Ntfs!NtfsMapStream+0x4b
30 ba021158 f727e623 Ntfs!ReadIndexBuffer+0x8f
174 ba0212cc f727e7c5 Ntfs!NtfsUpdateFileNameInIndex+0x62
fc ba0213c8 f727e905 Ntfs!NtfsUpdateDuplicateInfo+0x2b0
208 ba0215d0 f727b3f8 Ntfs!NtfsCommonCleanup+0x1ea1
170 ba021740 80840153 Ntfs!NtfsFsdCleanup+0xcf
14 ba021754 f731eb25 nt!IofCallDriver+0x45

So there are calls for reading NTFS data structures. Problem is we have
another system with exactly same configuration (Software and hardware) in
cluster where this problem does not occur.
Question:
1) Is there some way we can make NTFS data structure memory resident so that
they do not incur page fault.
2) What is the best way to resolve these error - this is causing recursion
in our driver and hence crash.

Thanks
Ashish

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer