Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit
From: Greg Lirette [MSFT] (gregoryl_at_online.microsoft.com)
Date: 06/23/04
- Next message: Greg Lirette [MSFT]: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Previous message: Greg Lirette [MSFT]: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- In reply to: Lehman's Old-time Hardware - System Administrator: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Next in thread: Lehman's Old-time Hardware - System Administrator: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 23 Jun 2004 15:22:07 -0500
If we think a newer ntfs.sys will help we can get you that, perhaps the
memory.dmp would should this
-- This posting is provided "AS IS" with no warranties, and confers no rights. "Lehman's Old-time Hardware - System Administrator" <sysadmin-N-O-SP-AM@lehmans.com> wrote in message news:u9SNtvGWEHA.1764@TK2MSFTNGP10.phx.gbl... > Found a difference in the ntfs.sys file: > > The version on the problem server is 5.0.2195.6710 dated 12/31/1979 8:00 > PM > The version on the test VPC server is 5.0.2195.6753 dated 5/8/2001 8:00 AM > > Note a couple other things: > > -Both servers report that they are at Service Pack 4 (in winver) > -The problem server lists 111 files in the C:\WINNT\system32\drivers > folder > as being created on 12/31/1979 8:00 PM > -The oldest file in the same folder on the test VPC server is 9/25/1999 > 6:35 > AM, of which there are 12 with that date. > > - The problem server came with Windows 2000 Server (OEM) SP4 > pre-installed. > - The test VPC server was setup using a Windows 2000 Server (OEM) SP2 > disc, > with SP3 and SP4 applied later. > > Today I will create a new VPC server with the Windows 2000 Server (OEM) > SP4 > disc that came with the problem server and see if that setup has the same > file dates and problems. I hope it does, because then I have something to > test possible solutions (such as re-applying SP4 or something). > > Let me know if you can think of anything else to try. > > Thanks, > > -djz > > > "Greg Lirette [MS]" <gregoryl@online.microsoft.com> wrote in message > news:eYtWurLVEHA.1048@tk2msftngp13.phx.gbl... >> No problem I am happy to assist. I can't really comment on the price but > I >> would assume you would be charged for a server incident. I don't really >> know how we charge, folks here may know better than me. >> >> you can use winmsd as a start to checkout the file dates. MPS reports >> (downloadable from our web site) is helpful as well. >> >> If you get a case opened please reference this thread and I can assist >> the >> case owner as well. If you wanted to try to get a memory.dmp file I >> would >> take a peek if you like. If you want to ping me offline with the path to >> the dump that would be fine. >> >> >> >> "Lehman's Old-time Hardware - System Administrator" >> <sysadmin-N-O-SP-AM@lehmans.com> wrote in message >> news:uPXa05KVEHA.2816@TK2MSFTNGP11.phx.gbl... >> Thanks for all the help you have been giving! >> >> How do I go about checking if the filter drivers are up-to-date? >> >> Would I be charged for opening a case with Microsoft? >> >> Thanks, >> >> -djz >> >> "Greg Lirette [MS]" <gregoryl@online.microsoft.com> wrote in message >> news:uKdtIUKVEHA.1764@TK2MSFTNGP10.phx.gbl... >> > No problem! >> > >> > I do suspect that mmc.exe is only a victim and the real issue is > whatever >> > the root cause is of the copy operation being so slow. It would not >> > surprise me if this is caused by a filter driver. Actually with a full >> > kernel dump it should show up. I would first see if your filter >> > drivers >> and >> > such are all up to date and perhaps disable them and see if it has an >> > impact. You may want to get a case opened with us. If you wanted to I >> > would look at a full dump of the issue. >> > >> > Info on getting a full dump is at >> > http://support.microsoft.com/?id=244139 >> > >> > >> > Thanks, >> > Greg Lirette >> > >> > "Lehman's Old-time Hardware - System Administrator" >> > <sysadmin-N-O-SP-AM@lehmans.com> wrote in message >> > news:eeOcSGKVEHA.212@TK2MSFTNGP12.phx.gbl... >> > Thanks for the reply. >> > >> > I tried the copy command you suggested and it took about 3 minutes. > Kinda >> > long for a file that is less than 1 MB. >> > >> > Does this mean that the problem with the GPO MMC is simply the >> manifestation >> > of a problem that could be related to other issues with this server, > such >> as >> > random performance "issues?" >> > >> > What should I do next? Is there anything that I can do or check to >> > help >> fix >> > resolve this problem? >> > >> > Thanks, >> > >> > -djz >> > >> > ""Greg Lirette [MSFT]"" <gregoryl@online.microsoft.com> wrote in >> > message >> > news:lHKtBZJVEHA.2980@cpmsftngxa10.phx.gbl... >> > > >> > > Thanks, the dump was helpful in getting us further! >> > > >> > > >> > > The dump is a snap shot in time so a different dump may show a > slightly >> > > different thing. Also this wasn't a complete memory dump but rather >> only >> > > mmc.exe so I only have the data available in that processes address >> space. >> > > >> > > Gptext.dll is loaded in the mmc.exe process, it spawned a new thread > in >> > the >> > > process, and the purpose of that thread is to load the ADM template. >> That >> > > thread is supposed to signal an event that it has done its work and >> > > we >> can >> > > proceed. >> > > >> > > We wait for 250 ms and if it is not signaled we then load the wait >> cursor >> > > and wait forever for it to be signaled. That is the state of what >> > > you >> see >> > > in the interface, you are in wait mode. >> > > >> > > In the other thread we spawned we are trying to copy a file. It >> > > could >> be >> > > different depending on what you clicked on but in this particular >> > > dump >> the >> > > file name is >> > > >> > > ( I have removed your company name and replaced with MyCompany) >> > > >> > > The operation we are performing is a copy with the following > parameters >> > > >> > > Source file >> > > >> > >> > \\MyCompany.lan\SysVol\MyCompany.lan\Policies\{DD8110D3-28F1-4DCE-A19C-7BA9B >> > > 5FE601C}\Adm\conf.adm >> > > >> > > Destination file >> > > C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\adm2.tmp >> > > >> > > If the file exists override it >> > > >> > > I suspect if you performed the following command you would see a hang > as >> > > well >> > > >> > > Copy >> > > >> > >> > \\MyCompany.lan\SysVol\MyCompany.lan\Policies\{DD8110D3-28F1-4DCE-A19C-7BA9B >> > > 5FE601C}\Adm\conf.adm C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\adm2.tmp >> > > >> > > >> > > From this dump I cannot tell you anything beyond this because we are >> only >> > > looking at user mode space and we now transition into kernel mode to > do >> > the >> > > copy. I am not sure from the dump if we are trying to access a >> > > server >> > that >> > > is our self or if it is remote. It could be a network issue, but I >> > suspect >> > > it may be our self and that it may be a filter driver in the kernel. >> > > Either way it would be interesting to see if you can eliminate the >> mmc.exe >> > > process by using a simply copy at the command line to reproduce the >> hang. >> > > >> > > The call stack and info about the kernel transition follows: >> > > >> > > ChildEBP RetAddr Args to Child >> > > 02b9efb4 7c578328 02b9f058 80100080 02b9eff4 ntdll!NtCreateFile+0xb >> > > 02b9f050 7c58e2b9 00000000 80000000 00000001 > KERNEL32!CreateFileW+0x343 >> > > 02b9f650 7c58e65e 02b9fd9c 02b9f8f4 00000000 >> > KERNEL32!BasepCopyFileExW+0x10c >> > > 02b9f6ac 7c59f18c 02b9fd9c 02b9f8f4 00000000 >> > > KERNEL32!CopyFileExW+0x52 >> > > 02b9f6c8 6fa479b2 02b9fd9c 02b9f8f4 00000000 KERNEL32!CopyFileW+0x1c >> > > 02b9fb34 6fa47870 02b9fd9c 6becbeb8 6fa40000 >> > > gptext!CPolicyComponentData::ParseTemplate+0xeb >> > > 02b9ffa8 6fa47282 6becbeb8 0001003f 7c57438b >> > > gptext!CPolicyComponentData::LoadTemplates+0x214 >> > > 02b9ffb4 7c57438b 00c374d8 6becbeb8 0001003f >> > > gptext!CPolicyComponentData::LoadTemplatesThread+0x20 >> > > 02b9ffec 00000000 6fa47262 00c374d8 00000000 >> KERNEL32!BaseThreadStart+0x52 >> > > 0:003> u ntdll!NtCreateFile ntdll!NtCreateFile+0xb >> > > ntdll!ZwCreateFile: >> > > 77f87cac b820000000 mov eax,0x20 >> > > 77f87cb1 8d542404 lea edx,[esp+0x4] >> > > 77f87cb5 cd2e int 2e >> > > >> > > Thanks, >> > > >> > > Greg Lirette >> > > >> > > This posting is provided "AS IS" with no warranties, and confers no >> > rights. >> > > >> > > >> > > >> > >> > >> > >> >> >> > >
- Next message: Greg Lirette [MSFT]: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Previous message: Greg Lirette [MSFT]: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- In reply to: Lehman's Old-time Hardware - System Administrator: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Next in thread: Lehman's Old-time Hardware - System Administrator: "Re: MMC.exe stops responding for up to 5 minutes during AD GPO browse / edit"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|