0x80070035 error in Windows 7 professional

I have a PC with windows 7 professional SP1, with LAN card Realtek PCie GBE family controller Phy:RTL8211/8212, DriverVer 08/23/2011, 7.048.0823.2011
CatalogFile.NT = rt64win7.cat.
When I browsing Internet all go fine no error is reached, when I send file to another PC with VISTA HP SP2 on the same LAN group through a Switch Ethernet NETGEAR 10/100/1000 after 30 GB data the system Windows 7 lost the LAN configuration (80070035), to resolve I must restart Windows 7. I tried to configure NETBIOS on TCP but without resolve the problem. I tried also another Swith Zyxel 10/100 with the same result.
Can someone help me to understand the problem?
Thanks
Best Regards

 

Really need you to post the exact error of what is shown. No way of knowing exactly what caused the error, with what you posted.

 

Hi,

You don't say whether or not this worked, and stopped, or has never worked.
It helps to know that.

I'll assume that this is the first time you've tried to do this, and proceed from there.

I'd start with the simple things: Verify that the network drivers on the Windows 7 computer are up-to-date. August 2011 is fairly new, but you never know (especially with Realtek chipsets). Do the same on the other end, on general principles.

Since you swapped the switch out with the same results, I'd discount that as an issue.

However, that doesn't eliminate cabling.

Verify that the cables are connected fully, and that the clips snap into place fully. Weak, broken or missing clips can result in poor/marginal connections that may not manifest any problems until the connection is stressed, such as during a high-speed sustained data transfer.

Also verify that the cables are rated to be handle the connection speed: Cat 5 for 100Mbps, Cat 5e or 6 for 1 Gbps. Since you state that it also fails with a 10/100 switch, I doubt that it's a speed rating issue, since I've not seen a cable rated for anything slower than Fast Ethernet in a very long time.

However, sustained data transfers at 100 Mbs and up can sometimes trigger issues (especially poor terminations) that wouldn't show up under normal use.
I'd swap the cables, one a time, if possible, with known-good ones to eliminate that as a problem. Naturally, I'm assuming that these are single direct-run cables, with no patch panels or patch cables or wallplates involved. Troubleshooting cabling in that scenario is more time-consuming, especially without a cable tester.

I'd also check the duplexing. If it's set for auto-duplex detection on either end, force it to full duplex on both, *assuming* that both sides are capable of it (they should be these days). Again, I haven't seen a duplex auto-detection issue in a long time, either, but then again, coming from an corporate networking background, I hard code the speed and duplex ratings to be the same on both ends as a matter of course: That way I KNOW that there's no possibility of a duplex or speed mismatch, which eliminates such as a possibility when troubleshooting.

However, if it were a duplexing issue, I'd expect it to manifest itself in some way before this. Still, it's something to check.

I'm not quite sure what you mean by that - are you using VLANs? If you are, and you can do so, eliminate them and see if you get the same results. VLANs aren't generally needed on small networks, which I'm assuming this is.

Assuming that none of this resolves the problem, verify that the file systems are OK on both sides by running a CHKDSK /F on both computers. If you get errors with CHKDSK /F, consider running CHKDSK /R to have Windows scan the drive surfaces (this can take a long time - and sometimes errors with CHKDSK /F aren't caused by physical problems with the drive).

If that doesn't work, I'd look at software, starting with AV software. TEMPORARILY disable whatever real-time scanning you have set up, on both sides, and then test. If the copy works, you can narrow it down by enabling one side, testing, and then the other, and testing again.

That's about all I have at this point, without the results of the above to work with.

Try the above, and post the results. Just off the cuff, I'd suspect cabling first, with AV software being second... and you could start "top down", by eliminating the software first, if you wished. It'd be less time-consuming if that turned out to be the culprit.

Regards,

dj

 

Yes, because I did not understand what caused the error, the error occurs after long download randomly without any apparent reason.
Regards

 

Thanks for the explanations and timely technical considerations about possible connection problems. As soon as possible to carry out the tests you mentioned.
Best Regards

 

That error only occurs due to a sharing issue, or when a computer is on a domain. Look through Event Viewer in Administrative tools and see if you can find the error, and post what it states.

 

Thanks, brownizs! I didn't know that, and it leads to another testing possibility: Instead of using SMB, he could try FTP.

There are number of free FTP servers available here: I use FileZilla, and it's easy to set up.

That would eliminate Windows networking to a large extent, and if it worked, would point in that direction. If it didn't, then I'd definitely pursue troubleshooting the cabling.

Regards,

Darrin

 

FTP has too many holes in it. There is nothing wrong with SMB. What the OP needs to do, is post the exact error that is happening, and software that is being used at the time that he gets the error.

 

I wasn't proposing it a a final solution or fix to the problem, but merely as a means to narrow down where the source of the problem might lie. Perhaps I didn't make that as clear as I could have.

Nor was I suggesting that there was anything wrong with SMB in general [1]. I'm not quite sure how you inferred that from my post.

FTP might not be secure, but the risks would be minimal, since he states that both computers are connected to the same switch.

Yes, it would be helpful to know the exact error. However, the approach I suggested is valid, if unconventional, and would help to narrow down the source of the problem even without it, at the expense of some time.

Regards,

dj


Notes:

[1] Except to say that SMB isn't nearly as nice a network protocol as, for example, NCP, technically speaking, although SMB v2.x is a lot nicer, far less chatty and much more efficient than older versions. In typical Microsoft fashion, they'll just keep at it until it's almost perfect, and then replace it with something new, I imagine :-D