Your question, your audience. Choose who sees your identity—and your question—with question security.
RPC Server is unavailable in Windows NT 4
I am running Windows NT 4 server with SP 6a on Dell PowerEdge 2500. Very often I get the error message "RPC server unavailable".
When this happens, can't open IE, several services from control panel can' run or open, all network shares are unavailable to other computers on the LAN. Getting the same error when I try these.
Any solution help?
Appreciate.
When this happens, can't open IE, several services from control panel can' run or open, all network shares are unavailable to other computers on the LAN. Getting the same error when I try these.
Any solution help?
Appreciate.
Who is Participating?
When the error occurs, Dr. Watson error window appears with "Services.exe" exception error.
There are no logs recorded in the Event viewer, can't locate Dr. Watson error log.
I did reapply SP6a. I changed memory (2 GB RAM) also.
I greatly appreciate your prompt help.
Thanks
There are no logs recorded in the Event viewer, can't locate Dr. Watson error log.
I did reapply SP6a. I changed memory (2 GB RAM) also.
I greatly appreciate your prompt help.
Thanks
A scheduled reboot more often than the error occurs to keep all memory pools etc. from being eaten up so quickly :-) .... Have been working recently with a ~2,500 server NT4 network migrating to 2003 and this plus other such errors are more or less part of life on NT4. How often is the occuring, daily, weekly?
Is there anything in the event log that gives you more information about the error?
Look in both the system and application logs.
There should be an event for the Dr Watson is there anything just before it?
Look in both the system and application logs.
There should be an event for the Dr Watson is there anything just before it?
I don't see any event in the Event viewer before/after Dr. Watson error. After Dr. Watson, even the Event viewer can't be opened. The server has to be rebooted when the server functions normally till the error occurs (some times daily).
I can reboot the server and clear both System and application logs in the event viewer and look for the entry in the logs when Dr. Watson error occurs.
Is there switch to turn on/off Dr. Watson log? in NT.
Thanks
I can reboot the server and clear both System and application logs in the event viewer and look for the entry in the logs when Dr. Watson error occurs.
Is there switch to turn on/off Dr. Watson log? in NT.
Thanks
http://support.microsoft.com/?kbid=188296&sd=RMVP
details how to turn off Dr Watson.
However in looking into this I stumbled across an exploit for a DOS attack which after being tested against SP1 - SP6a NT4 was vulnerable.
Don't know if it's what you are getting, but it kills services.exe, causing a Dr Watson.
"> The impact is pretty severe. Services.exe handles named pipes for
> the system. Once this crashes, everything named-pipe-based goes with it.
> This means logons, logouts, remote system access (registry, server
> functions, etc), local server management, IIS, file sharing, etc...all go
> down the tube. However, the box will, for the most part, appear to
> function normally on the local side, until you do something involving a
> named pipe service. The only fix is to reboot."
Event viewer uses named pipes to connect to the machine.
details how to turn off Dr Watson.
However in looking into this I stumbled across an exploit for a DOS attack which after being tested against SP1 - SP6a NT4 was vulnerable.
Don't know if it's what you are getting, but it kills services.exe, causing a Dr Watson.
"> The impact is pretty severe. Services.exe handles named pipes for
> the system. Once this crashes, everything named-pipe-based goes with it.
> This means logons, logouts, remote system access (registry, server
> functions, etc), local server management, IIS, file sharing, etc...all go
> down the tube. However, the box will, for the most part, appear to
> function normally on the local side, until you do something involving a
> named pipe service. The only fix is to reboot."
Event viewer uses named pipes to connect to the machine.
Very close analysis and this is exactly what happens when Dr. Watson error occurs.
Can you be kind to suggest what I need to do to fix this problem?
I will visit the above link.
I appreciate the much needed help.
Thanks
Can you be kind to suggest what I need to do to fix this problem?
I will visit the above link.
I appreciate the much needed help.
Thanks
Terry,
You helped me in a big way to narrow RPC problem to blocking the 139 on the firewall. Since that blocking, RPC is running in full mode, meaning all the services supported by it are running fime. You deserve more than 1000 points.
I have another problem with NT 4 server.
I am trying to find working LINK SHELL EXTENSION software utility for NT 4 server. Can you suggest one?
Thanks
Hosali
You helped me in a big way to narrow RPC problem to blocking the 139 on the firewall. Since that blocking, RPC is running in full mode, meaning all the services supported by it are running fime. You deserve more than 1000 points.
I have another problem with NT 4 server.
I am trying to find working LINK SHELL EXTENSION software utility for NT 4 server. Can you suggest one?
Thanks
Hosali
WOW, OK.
Blocking port 139 was one of the work arounds for the exploit but that supposedly didn't stop internal attacks.
Heres the link to the exploit details from WAYYYYY back in 1999.
http://www.wiretrip.net/rfp/txt/rfp9906.txt
And here for more information from Microsoft about malformed packets causing services.exe to die (And hence named pipes).
http://www.microsoft.com/technet/security/bulletin/fq99-055.mspx
Try here for a post SP6a hotfix from Microsoft.
http://support.microsoft.com/default.aspx?scid=kb;en-us;246045&sd=tech
(I just found the microsoft links today, Sorry)
For Link Shell Extension this is one I've tried before.
It supports back to NT4
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
But Junctions can only be made under Win2k and above.
Hard links are fine though.
Or as that page says "They can be created with the POSIX command ln included in the Windows Resource Kit or the fsutil command utility included in Windows XP. "
Glad the server is stable now.
Terry
Blocking port 139 was one of the work arounds for the exploit but that supposedly didn't stop internal attacks.
Heres the link to the exploit details from WAYYYYY back in 1999.
http://www.wiretrip.net/rfp/txt/rfp9906.txt
And here for more information from Microsoft about malformed packets causing services.exe to die (And hence named pipes).
http://www.microsoft.com/technet/security/bulletin/fq99-055.mspx
Try here for a post SP6a hotfix from Microsoft.
http://support.microsoft.com/default.aspx?scid=kb;en-us;246045&sd=tech
(I just found the microsoft links today, Sorry)
For Link Shell Extension this is one I've tried before.
It supports back to NT4
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
But Junctions can only be made under Win2k and above.
Hard links are fine though.
Or as that page says "They can be created with the POSIX command ln included in the Windows Resource Kit or the fsutil command utility included in Windows XP. "
Glad the server is stable now.
Terry
Oh, Hosalin,
Could you please accept the answer that helped you pin down the problem, that way other people can see what the accepted answer was easily.
(The microsoft links especially the post SP6a link above might fix it totally, but port 139 should only be open for internal network at a maximium)
Thanks,
Terry.
Could you please accept the answer that helped you pin down the problem, that way other people can see what the accepted answer was easily.
(The microsoft links especially the post SP6a link above might fix it totally, but port 139 should only be open for internal network at a maximium)
Thanks,
Terry.
Actually dragon, I've found 3-4 other posts all sounding VERY similar in this forum.
RPC dieing, one mentioned services.exe
Perhaps people have found a new way to hack port 139 under NT via netbios.
If the SRP don't fix it, it would seem going to Win2k or disabling port 139 would be the only way to minimise the impact of this.
Terry
RPC dieing, one mentioned services.exe
Perhaps people have found a new way to hack port 139 under NT via netbios.
If the SRP don't fix it, it would seem going to Win2k or disabling port 139 would be the only way to minimise the impact of this.
Terry
Erm, while I hate to thow away 2000 points, is that the answer you intended to select? If hosalin doesn't respond other experts please suggest who you think should have got points and I will post Community Support Q.
Steve
Steve
Ummm, OK,
Well it seems since I was the only one to give up the option of port 139 being the hastle you get the points steve.
Considering there are post SP6a fixes that might fix this and the
"Terry,
You helped me in a big way to narrow RPC problem to blocking the 139 on the firewall. Since that blocking, RPC is running in full mode, meaning all the services supported by it are running fime. You deserve more than 1000 points."
perhaps a review of this question and accepted answer might be in order.
Terry
Well it seems since I was the only one to give up the option of port 139 being the hastle you get the points steve.
Considering there are post SP6a fixes that might fix this and the
"Terry,
You helped me in a big way to narrow RPC problem to blocking the 139 on the firewall. Since that blocking, RPC is running in full mode, meaning all the services supported by it are running fime. You deserve more than 1000 points."
perhaps a review of this question and accepted answer might be in order.
Terry
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month10 days, left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
I'm still doubtful it's using this exploit or if the hole still exists, It's been a LONG time since I tested NT4 fully patched for known exploits.
The solutions to this were waiting on a fix from Microsoft dating back to Quarter 4 of 1999. I don't know if it ever got fixed in either NT or win9x.
But for NT4 for anything to kill services.exe will produce the same results. Getting to the root cause of services.exe dieing will get you a fix.
1) a repair install on NT. Take it down completely, disconnect it from the network and install over the top from an original NT install CD, then apply SP6a from a CD or whatever before connecting it to the network.
Make sure you have any third party up to date drivers needed to talk to SCSI controllers or raid arrays/other essential devices on floppy or CD before you begin and overwrite any files it says are newer.
(I.E your 3rd party drivers would override any from NT4 the original install CD)
2) If this is a frontward facing server to the internet, block port 139 on your firewall for incoming internet traffic for that server unless it's really needed to be open.
I still doubt this exploit is being used, but If, BIG IF this exploit still exists then the suggested way to stop it from being used is not viable for a server. It was a stop gap for VERY short term.
Is there anything that happens in the event logs JUST before it happens.
Turn on all logging, successful and unsucessful if you suspect someone would be willing to try this.
Terry