FRS Invalid Parameter Errors

J

James Palic

We have a simple setup - two sites each with a W2K3 DC.

Back in February the SYSVOL stopped replicating. AD info
seems to be replicating just fine. DNS seems to be working. DCDIAG
doesn't report any issues. I can ping and nslookup the FQDN of each
DC as well as the domain name.

We have one other DFS directory that replicates between these two DC's
and it seems to replicate ok.

There are no errors in the event log. But I'm seeing in the
%systemroot%\debug\ntfrs_????.log files a series of entries that looks
like this for each file that is attempting to replicate:

=============================================
<StuExecuteInstall: 3036: 2271: S1: 12:03:08> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

<ProcessOpenByIdStatus: 3036: 3010: S1: 12:03:09> ++ EB040000
00002BF0 Fid Open failed; NTStatus: STATUS_INVALID_PARAMETER

<FrsOpenSourceFileById: 3036: 3360: S0: 12:03:09> ++ ERROR -
NtCreateFile failed : NTStatus: STATUS_INVALID_PARAMETER

<StuOpenDestinationFile: 3036: 653: S0: 12:03:09> :: CoG
4def00c1, CxtG 4e1ae42a, FV 0, FID eb040000 00002bf0, FN:
Policies_NTFRS_038bdbf6, [FrsForceOpenId failed.
(ERROR_INVALID_PARAMETER)]

<StuExecuteInstall: 3036: 2271: S1: 12:03:09> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

=============================================

The only error condition I'm seeing in SONAR is a long join cycle on
one of the DC's.

A week or so ago I did an authoritative restore by setting the
BURFLAGS to D4 on one box and D2 on the other and the inital
replication occurred ok. But changes since then don't replicate. I
tried the authoritative restore again but it didn't work this time.

I'd really like to figure out how to fix this without totally starting
over but I don't even know where to begin. Any thoughts?

Thanks.

Jim
 
J

James Palic

I just wanted to close the loop on this and note the resolution in
case anybody else runs into the same problem.

After weeks of troubleshooting with Sonar/Ultrasound/Ntfrsutl and
various other AD and replication tools, I decided to try to get a
better idea of what was creating the STATUS_INVALID_PARAMETER message
in the NTFRS Debug logs since this seemed to be the root of the
problem.

I loaded the Filemon utility from www.sysinternals.com and monitored
the NTFRS service. I found that there was an IOCTL call failing and
whenever the IOCTL call failed I saw the STATUS_INVALID_PARAMETER
message in the NTFRS debug logs.

The Filemon log looked like this:

ntfrs.exe: FASTIO_DEVICE_CONTROL C:\winnt FAILURE IOCTL:
0x4D0008
ntfrs.exe: IRP_MJ_DEVICE_CONTROL C:\winnt INVALID PARAMETER IOCTL:
0x4D0008

Apparently IOCTL: 0x4D0008 translates to IOCTL_QUERY_DEVICE_NAME.

I ran Filemon on the other DC's in our setup and noticed with much
interest that none of them used IOCTL's. IOCTL calls are made to low
level drivers in the OS. It occurred to me that perhaps something
about the interaction of Windows with the hardware was amiss.

It occurred to me that perhaps running on different hardware might
either fix the problem or produce other symptoms that would help to
troubleshoot. So I decided to move the drive from the DC with the
non-replicating SYSVOL to another computer.

I first cloned the drive so that I could go back to it if need be and
then put the cloned drive into a completely different computer. I
reran the Windows Server setup and had it repair the installation so
that it would pick up the new hardware settings.

When I booted the new system I found that the File Replication Service
worked perfectly. I don't have any idea of the underlying issue but
this workaround ended weeks of messing around with this issue.

Good luck!

We have a simple setup - two sites each with a W2K3 DC.

Back in February the SYSVOL stopped replicating. AD info
seems to be replicating just fine. DNS seems to be working. DCDIAG
doesn't report any issues. I can ping and nslookup the FQDN of each
DC as well as the domain name.

We have one other DFS directory that replicates between these two DC's
and it seems to replicate ok.

There are no errors in the event log. But I'm seeing in the
%systemroot%\debug\ntfrs_????.log files a series of entries that looks
like this for each file that is attempting to replicate:

=============================================
<StuExecuteInstall: 3036: 2271: S1: 12:03:08> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

<ProcessOpenByIdStatus: 3036: 3010: S1: 12:03:09> ++ EB040000
00002BF0 Fid Open failed; NTStatus: STATUS_INVALID_PARAMETER

<FrsOpenSourceFileById: 3036: 3360: S0: 12:03:09> ++ ERROR -
NtCreateFile failed : NTStatus: STATUS_INVALID_PARAMETER

<StuOpenDestinationFile: 3036: 653: S0: 12:03:09> :: CoG
4def00c1, CxtG 4e1ae42a, FV 0, FID eb040000 00002bf0, FN:
Policies_NTFRS_038bdbf6, [FrsForceOpenId failed.
(ERROR_INVALID_PARAMETER)]

<StuExecuteInstall: 3036: 2271: S1: 12:03:09> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

=============================================

The only error condition I'm seeing in SONAR is a long join cycle on
one of the DC's.

A week or so ago I did an authoritative restore by setting the
BURFLAGS to D4 on one box and D2 on the other and the inital
replication occurred ok. But changes since then don't replicate. I
tried the authoritative restore again but it didn't work this time.

I'd really like to figure out how to fix this without totally starting
over but I don't even know where to begin. Any thoughts?

Thanks.

Jim
Click to expand...
 
J

Jack Hawkins

Seems like a slighly crude workaround but nevertheless, effective


James Palic said:
I just wanted to close the loop on this and note the resolution in
case anybody else runs into the same problem.

After weeks of troubleshooting with Sonar/Ultrasound/Ntfrsutl and
various other AD and replication tools, I decided to try to get a
better idea of what was creating the STATUS_INVALID_PARAMETER message
in the NTFRS Debug logs since this seemed to be the root of the
problem.

I loaded the Filemon utility from www.sysinternals.com and monitored
the NTFRS service. I found that there was an IOCTL call failing and
whenever the IOCTL call failed I saw the STATUS_INVALID_PARAMETER
message in the NTFRS debug logs.

The Filemon log looked like this:

ntfrs.exe: FASTIO_DEVICE_CONTROL C:\winnt FAILURE IOCTL:
0x4D0008
ntfrs.exe: IRP_MJ_DEVICE_CONTROL C:\winnt INVALID PARAMETER IOCTL:
0x4D0008

Apparently IOCTL: 0x4D0008 translates to IOCTL_QUERY_DEVICE_NAME.

I ran Filemon on the other DC's in our setup and noticed with much
interest that none of them used IOCTL's. IOCTL calls are made to low
level drivers in the OS. It occurred to me that perhaps something
about the interaction of Windows with the hardware was amiss.

It occurred to me that perhaps running on different hardware might
either fix the problem or produce other symptoms that would help to
troubleshoot. So I decided to move the drive from the DC with the
non-replicating SYSVOL to another computer.

I first cloned the drive so that I could go back to it if need be and
then put the cloned drive into a completely different computer. I
reran the Windows Server setup and had it repair the installation so
that it would pick up the new hardware settings.

When I booted the new system I found that the File Replication Service
worked perfectly. I don't have any idea of the underlying issue but
this workaround ended weeks of messing around with this issue.

Good luck!

(e-mail address removed) (James Palic) wrote in message
We have a simple setup - two sites each with a W2K3 DC.

Back in February the SYSVOL stopped replicating. AD info
seems to be replicating just fine. DNS seems to be working. DCDIAG
doesn't report any issues. I can ping and nslookup the FQDN of each
DC as well as the domain name.

We have one other DFS directory that replicates between these two DC's
and it seems to replicate ok.

There are no errors in the event log. But I'm seeing in the
%systemroot%\debug\ntfrs_????.log files a series of entries that looks
like this for each file that is attempting to replicate:

=============================================
<StuExecuteInstall: 3036: 2271: S1: 12:03:08> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

<ProcessOpenByIdStatus: 3036: 3010: S1: 12:03:09> ++ EB040000
00002BF0 Fid Open failed; NTStatus: STATUS_INVALID_PARAMETER

<FrsOpenSourceFileById: 3036: 3360: S0: 12:03:09> ++ ERROR -
NtCreateFile failed : NTStatus: STATUS_INVALID_PARAMETER

<StuOpenDestinationFile: 3036: 653: S0: 12:03:09> :: CoG
4def00c1, CxtG 4e1ae42a, FV 0, FID eb040000 00002bf0, FN:
Policies_NTFRS_038bdbf6, [FrsForceOpenId failed.
(ERROR_INVALID_PARAMETER)]

<StuExecuteInstall: 3036: 2271: S1: 12:03:09> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_FILE_NOT_FOUND

=============================================

The only error condition I'm seeing in SONAR is a long join cycle on
one of the DC's.

A week or so ago I did an authoritative restore by setting the
BURFLAGS to D4 on one box and D2 on the other and the inital
replication occurred ok. But changes since then don't replicate. I
tried the authoritative restore again but it didn't work this time.

I'd really like to figure out how to fix this without totally starting
over but I don't even know where to begin. Any thoughts?

Thanks.

Jim
Click to expand...
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Sysvol Not Replicating 2
NTFRS EVENT 13508 1
Re: Help understanding FRS log files in 0
RPC probs with Ntfrs through firewall 1

Top