Page 1 of 1

InCD conflict with AT&T DSL Connection S/W

PostPosted: Sat Sep 27, 2003 11:52 am
by CowboySlim
Well, Buckaroos, I finally went up to broadband with the AT&T DSL service (who appears to be a reseller for Covad who in turn leases the landlines from Verizon (my local telco).

The DSL connection is functional. However, when I boot (Windows XP Home, SP1a), I get the following (which I assume comes from InCD, v 4.0.5.6): "Cannot connect to the file system. InCD service not running."

I did a restore prior to AT&T installation, uninstalled InCD, rebooted, reinstalled AT&T DSL connection S/W, then reinstalled InCD, rebooted and still get the same message and InCD doesn't load.

Any tips, ideas, similar experience?

Thanks,

PostPosted: Sat Sep 27, 2003 12:27 pm
by dburg
So without the DSL software InCD works fine? :o

PostPosted: Sat Sep 27, 2003 2:55 pm
by CowboySlim
Oh yes, David, thank you for the quick response.

I should have explicitly stated such. I've had no problem with any version of InCD in quite a while. (The only issue was solved with great assistance in this forum earlier this year and was not traceable to InCD). As such, either I've been quite fortunate in contrast to some of the others here or, on the other hand, I just don't know outside of the fact that I'm quite satisfied with the product.

A personal note: I've spent many years developing S/W myself. Starting with FORTRAN II and the punched card decks and most recently with the VBA language embodied in the Professional Edition of Microsoft Office. I feel great sympathy for both you and Craig at the level of intensity of some of the complaints regarding the "bugs" in your S/W that are posted herein by some respondents. Unfortunately, we share a common experience, I've been on the receiving end all too often myself. Too bad we can't have a complaint filter, comparable to a SPAM or virus filter, that filters out the complaints from those who have never developed S/W themselves.

Appreciatively yours,

PostPosted: Sat Sep 27, 2003 5:31 pm
by cfitz
CowboySlim wrote:Too bad we can't have a complaint filter, comparable to a SPAM or virus filter, that filters out the complaints from those who have never developed S/W themselves.

Oh, come on Slim! If you develop software for a living you should know better than that. I am surprised to to see something like this coming from you. Are you kissing up to dburg or have you been in the ivory tower for too long?

I develop software for a living as well, and I have been at both ends of the bug complaint pipeline. From that experience, I know that the "blame the user" or "only professionals can properly recognize and report a bug" mentality that you are dancing with in your last post is not the proper attitude for a developer to take. Users are quite capable of recognizing and reporting bugs. And in the end, they are the ultimate arbiters of a piece of software's quality. It the users can't use the software without problems, that software isn't any good. If you ignore the experience of end users, you are shooting yourself in the foot, discarding some of the best information for improving your product, and setting yourself up for eventual failure. Remember, the users are the ones paying for the product, and if they don't like it, they will go elsewhere.

It is true that there has been a lot of complaining about the bugs in Nero 6, and some of those complaints may be over the top, but on the whole the complaints are valid and deserved. It is transparently evident, given the multiple false starts and delays in releasing Nero 6, that Ahead was having big troubles getting it out the door. From the number of quite significant bugs that have been found since then, it appears that even with the delays the final product was still rushed, released prematurely, and has yet to settle down.

With as much experience as you have listed, I would think you would be able to watch what has been happening with Nero of late and easily recognize what has been going on. Of course, maybe you have been fortunate enough or skilled enough to never have been involved in a problematic project, and that makes it harder for you to recognize the chaos behind the closed doors. 8)

Respectfully,

cfitz

PostPosted: Sat Sep 27, 2003 6:14 pm
by dburg
Well, myself I will stick to the defect report. And yes it has been seen by other end-users, so far not especially with DSL software, without Ahead QA been able to reproduce it. So with latest InCD's updates we've added some additional debug output to the log files about the startup.

Can you post here as attachement or send me by e-mail the 2 log files of InCD, CowboySlim?

PostPosted: Sat Sep 27, 2003 6:56 pm
by CowboySlim
No, cfitz, I wasn't a--kissing, it was venting. Most recently, the (my) user was in the office next to me and a six sigma complainer. Worse yet, everthing that went bad was immediately shouted up and down the aisle as another bug in my software when 90% of the time, after hours chasing down a non-bug, I found another mistake on his part that had nothing to do with any bug in my S/W itself. Predictably, no apololgy was ever forthcoming. Well, here is my apology, as I offered mis-leading diagnostic evidence.

I have a second HDD, with a bootable, similar OS, on the other IDE channel. The DSL connection S/W has NOT been installed there. However, it does have a parallel installation of Nero & InCD. Well, it just goes to show you, the same InCD comment arose when I booted into that HDD just a while ago. Then I realized the other new piece of the puzzle: also new was the Linksys 10/100 LAN Card, model LNE 100TX ver 5.1, which of course, I had just installed.

So between now and then I disabled the card thru Device Manager and rebooted (back to the first HDD, now). Rebooted and InCD came up just fine and tested the InCD with a D&D copy, OK. Enabled the card thru DM and connected to the ISP. Then tested InCD D&D copy again and OK.

Well, in a functional sense everything works as of this minute. In an operational context, disabling the card prior to shutdown and re-enabling subsequent to boot-up is nasty.

I'll reboot with out the disable to generate the "incident" (no bug intended) and be right back with the log.

PostPosted: Sat Sep 27, 2003 7:55 pm
by cfitz
CowboySlim wrote:No, cfitz, I wasn't a--kissing, it was venting. Most recently, the (my) user was in the office next to me and a six sigma complainer. Worse yet, everthing that went bad was immediately shouted up and down the aisle as another bug in my software when 90% of the time, after hours chasing down a non-bug, I found another mistake on his part that had nothing to do with any bug in my S/W itself. Predictably, no apololgy was ever forthcoming.

That I do understand and sympathize with you on. All I can offer in way of condolences is that most of the time the truth will out, and people will see that he is the one not living up to his end of the bargain, not you.

One of the bigger projects I worked on last year depended on a lot of other software systems written by others. I work by the matra "never trust external inputs", so I included a lot of validation and logging code in my code even though it was a pain and added a lot of work for me. Sure enough, once my code was released to QC and to play full-time with the dependent systems, it started logging lots of errors.

At first people kept on saying, "There's another problem with cfitz's code," and I would have to track down the problem. Similar to your experience, the vast majority of the time the true source of the problem was actually an existing bug in someone else's code that no one had yet noticed but my code detected and flagged. Eventually people started saying "Cfitz's code has logged another error. There must be problem with John/Joe/Mary's code."

cfitz

PostPosted: Sat Sep 27, 2003 8:42 pm
by CowboySlim
Exactly, it sure teaches humility. I've gone on to another job now, a non-coding one. Now, I and others are first user's (beta testers, more appropriately) of Oracle code that is be developed in chunklets as fast as we can take it. I totally refrain from any negative connotation when I tell the developers of the latest "oh-oh".

PostPosted: Sat Sep 27, 2003 10:46 pm
by Justin42
While it sounds like things are generally working, have you tried using a router (to handle the DSL connection) and uninstalling the DSL software entirely?

I refuse to install DSL software on my computer(s), so I just got a cheapy Linksys BEFSR41 router and it does everything fine. :)

PostPosted: Sun Sep 28, 2003 12:50 am
by CDRecorder
I also won't install the ISP software on my computers. I use a router between my computers and the cable modem.

CowboySlim, did you try updating your NIC drivers? I know you probably already thought of it, but I didn't see you mention it anywhere...

BTW, I didn't know that you were software developers, Cfitz and CowboySlim! I develop software, too! :D

PostPosted: Sun Sep 28, 2003 1:15 am
by cfitz
CDRecorder wrote:BTW, I didn't know that you were software developers, Cfitz and CowboySlim! I develop software, too! :D

I started out life as an electrical engineer, and Slim is a thermodynamicist at heart. :) But software has a way of catching all of us eventually... :( :wink:

cfitz

PostPosted: Sun Sep 28, 2003 1:28 am
by CowboySlim
Hey Justin and CDR, what am I missing here? I don't have a router as there is no other computer to route to. I no longer think that the problem is with the ISP provided DSL connection S/W. Remember my last test: Disable the PCI Ethernet card in device manager, reboot with InCD loading properly, re-enable the card, connect with the S/W and then successfully D&D copy to a CD-RW disc.

So the issue seems to be that InCD won't load when the PCI card is enabled. It appears to be not involved with the connection S/W.

From that which you seem to suggest, if I had a router between my DSL modem and the PCI card, it will provide the connective function and the S/W is not needed? But I still need the card to get the CAT 5 cable into the PC and that is where I now think that the problem is.

???

Didn't think about the NIC drivers. And I was just there tonight, Intel D845GBEV2 mobo, to download and install a BIOS update, no change. However, I did put the LINKSYS CD in and update the PCI card driver from the XP driver, no change.

I'll check Intel for any NIC drivers in the AM. After I read the papers and check for a 256Mb CF card for cfitz. I'll try to post the biggest, best big box bargain buys by 7AM.

Alliteratively yours,

PostPosted: Sun Sep 28, 2003 1:33 am
by CDRecorder
Hi CowboySlim,

If you only have one computer, you don't need a router. Sorry about the confusion. :(

PostPosted: Sun Sep 28, 2003 1:36 am
by CDRecorder
A router can provide features such as a firewall, but you can get software to do that, too. Actually, Windows XP has a stripped-down firewall built in to the operating system that you can enable if you don't have some other type of firewall.

PostPosted: Sun Sep 28, 2003 11:00 am
by CowboySlim
I've got the XP firewall enabled now. I've got some others that have come with other stuff (Norton Internet Security, OnTrack System Suite's Internet Defense) or free versions (ZoneAlarm) that I've D/L'd. Also, Fry's is always offering a McAfee firewall free AMIR which includes an upgrade rebate, which frequently can be applied to competitive S/W.

I just might make an image of the bootable partition and load up everthing from scratch again (with a better firewall) and maybe the Linksys card/InCD issue will mystically not reappear.

PostPosted: Sun Sep 28, 2003 11:44 am
by cfitz
If InCD uses TCP or UDP for interprocess communication, there is some chance that firewall software installed as part of the DSL software could cause problems by blocking that communication. Using TCP or UDP for interpocess communication is not uncommon, but I kind of doubt something like InCD would do so.

cfitz

PostPosted: Sun Sep 28, 2003 12:22 pm
by CowboySlim
cfitz wrote:If InCD uses TCP or UDP for interprocess communication, there is some chance that firewall software installed as part of the DSL software could cause problems by blocking that communication. Using TCP or UDP for interpocess communication is not uncommon, but I kind of doubt something like InCD would do so.

cfitz


Good avenue to pursue. AFAIK, the AT&T DSL Connection S/W does not include firewall provisions. At least, I don't recall that it was claimed in their promo stuff. It appears as their installer sets up a customized XP Network Connection for you and they don't even enable the check box for the built-in Windows XP firewall for you. It may not make sense to me but it might turn up something meaningful for David.

PostPosted: Sun Sep 28, 2003 8:55 pm
by CowboySlim
I've look at that TCP, UDP lead some more and there may be something to it. If so, perhaps it manifests itself that makes me think that the PCI ethernet card is an issue. But here is what I've observed.

I've compared the Connection Panels for both the AT&T Dial UP and the AT&T DSL services against each other. Doing the Properties, Advanced, Settings tabs, I've noticed that the DSL includes two services (boxes checked) that the Dial UP doesn't have:
msmsgs 12345 TCP
msmsgs 67890 UDP

I tried to eliminate the effect, if any, of the installed A&T S/W so I uninstalled it. Then I rebuilt the connector suing the Windows XP Connection Wizard.

I turn the msmsgs things off and delete them but whenever I re-establish the connection, they come back checked. With the connection off, I deleted them and rebooted, they were still deleted. But when I reconnceted, they had reappeared.

However, during the reboot I still got the comment, noted above, from InCD and a failure to load. So apparently they don't affect the load of InCD and neither does any AT&T DSL connection S/W on MY machine.

PostPosted: Mon Sep 29, 2003 5:59 pm
by rbmorse
Slim,

Isn't MSMSGS the executable for Microsoft Messenger?

Does it make any dfference if you kill that puppy so it doesn't load on
IPL?

Regards

PostPosted: Tue Sep 30, 2003 12:03 am
by CowboySlim
Hey, RB,

Nice running into you over here! Yeah, that is what I guessed. I tried to kill that damn thing off earlier tonight when I had my distro CD in uninstalling my Outlook 97. But that stupid icon is still in my tray. I mean I got enough good buddies now, both here and there to talk to without that MS Messenger dealybob.

You know, CDRecorder, it's just like cfitz says, it can happen to anybody - just like getting hit by a drunk driver (well, I mean as a random event not necessarily tragic.) But back then there was no term "software developer", we were "programmers". We had FORTAN II, punched cards and tables of octal to decimal conversions. :roll:

PostPosted: Wed Oct 08, 2003 10:28 pm
by CowboySlim
Allow me to post some more recent observations.

I have uninstalled any AT&T DSL software. I used the Windows New Connection Wizard to make a "connector".

In response to RB's Messenger suggestion, I have de-activated that POS without affecting the conflict.

However, in addition to the workaround, noted above, of disabling/re-enabling the PCI Ethernet card in Device Manager, I've found another, more tractable workaround (if I can anticipate a near term need to packet write): Lean over and push the DSL modem switch to "off", re-boot (InCD launches normally), then lean over and switch the modem to "on", double click on the connector short cut and "I'm BAAAAAAAAACK!"

As Rosannadanna used to say: "That just goes to show you, it's always something, if it's not one thing, it's another...........

PostPosted: Mon Nov 17, 2003 10:16 pm
by dburg
Our techsupport has received reports of several users having a conflict between a network component of InCD.

From a technical point of view I cannot yet explain this. No, we are not using RPCs to communicate inside our components, but named pipes instead. That *should* be independent from network components of the system, shouldn't it?

We are trying to collect enough examples of this issue to then get our QA labs to succeed in reproducing it.

PostPosted: Tue Nov 18, 2003 3:12 pm
by CowboySlim
Thanks, David,

I appreciate the effort to resolve this. Since some time has passed since the last post of my observation, let me state that the observation is still relevant.

To restate: Rebooting with my DSL connection active results in a failure of InCD to load properly, I receive a comment to that effect and InCD is unavailable. When I boot up with the DSL modem "OFF", InCD loads properly. After InCD loads, I switch the modem "ON", re-establish the connection and everthing (including) InCD works properly.

This hasn't been a major impact as I shut the modem off nightly. I only have to remember not to turn it on until after I boot up the following day. The only irritation is when I have to reboot due to the periodic Windows/IE security update installations which require a reboot.