Moving to its own thread for better exposure
Iāll start by casually mentioning that the problem might be fixed.
Every time I come to this thread to post an update, I get hung up on what Allen_K did to the images on the second page. And then I donāt get around to posting the update.
Iām not criticizing Allen, although Iām willing to criticize the board software. The images I inserted caused the message body to become too wide (IMO thatās the fault of the board software). Allen changed the IMG tag in the html to resize the images.
That worked with Mozilla (in that it reduced the width of the message body), although I suspect not as well as Allen would have liked (the message body is still too wide). But it either didnāt work much with IE7, or it didnāt work at all. And the images are almost unreadable (which I can fix pretty easily if I could get past my other hang-up, which is that I havenāt managed to figure out why it didnāt work on IE7).
Setting that aside, hereās an update:
Symantec installed and ran a debug version of symlcsvc on my machine. It logged a variety of things, including the failure of the Smart-Get-Version controls. But it apparently was not set up to log anything about the SCSI-Pass-Through-Directās (SPTDs), and didnāt.
I submitted the problem to Seagate, acknowledging that they had no support responsibility. I got a couple of stock responses before I got escalated. Then they said that they could not help me, I would have to work through Dell.
I have been working with Dell, more or less continuously, since they got the system transferred into my name in late August. They apparently limit the period of time during which an analyst will work with a customer, so Iāve worked with a number of analysts.
One of them actually suggested that I just dump Symantec and suck it up. He claimed that; if the Dell diagnostics found nothing wrong with the system, there was nothing wrong with the system. I thought that was somewhat fatuous, particularly as he knew that I had found another way to trigger the hang. Please donāt tell Symantec, since I havenāt. The other way is very irregular, and hard to achieve. symlcsvc triggers it more than 50% of the time; the other way is less than 1%. I havenāt wanted to let Symantec off the hook because all Iām asking is what the SPTD does. Itās become pretty clear that theyāre never going to tell me, which is okay because Iāll dig it out eventually on my own.
Iām going to share a thought or two about that analyst, with Dell, after this is over. I have no complaints about any of the other Dell analysts.
I now have a permanent analyst assigned (weāll see how long he can put up with me<g>).
Iāve sent Dell a lot of information. At one point they called to try something on my machine. The analyst said that they had other people with the same problem, and that the common element appeared to be Symantec. He said that they thought that Symantec was loading an incorrect SATA driver, although he was not able to name the driver (donāt quote me as Iām sure Iām not quoting him accurately). He did not find anything like that on my machine.
I wanted to ask questions about the other people with the same problem, but he was focusing on following instructions and talking to an up-level technician while he was doing it; so I didnāt.
My problem qualifies as esoteric. Itās way beyond my level of expertise (almost zero in this area). Whenever I think that someone who might understand the process of executing an SPTD, is looking at it, I quit working it myself. This has not worked out well. It appears that such people are rare, and probably make too much money. I am now a full-fledged student of driver and I/O architecture (freshman class).
I have downloaded and installed nearly every free development and diagnostic tool that Microsoft offers. Including their Software Development Kit (SDK), Driver Development Kit (WDK, used to be DDK), and the Windows Logo Testing Kit (WLK, used to be WHDK).
I ran Driver Verifier set up to monitor the SCSI port and miniport drivers, with SCSI verification enabled. It would (by design) crash the system (generating a dump), whenever I started symlcsvc (SCSI timing parameters were always violated). I generated mini, kernel, and full memory dumps. I analyzed the dumps using Windbg.
Windbg does way too many things. It is a live kernel mode debugger (requires two machines), live user mode debugger, and a crash-dump analyzer. It changes modes freely and capriciously, although probably not for experts. When analyzing a dump, it is strongly oriented towards the cause of the dump. Thatās just what you want if youāre working on a BSOD. In my case it dutifully reported that the dump was caused by Driver Verifier, while it was executing a Dump command. I had to dig for the information I wanted, often unsuccessfully; and, if I wasnāt careful, it would start to report information from the running system rather than the dump.
Iāve seen rumors that a lot of this is simpler if you have source code for the programs youāre interested in, and a checked build of Windows.
I decided that Driver Verifier was actually getting in my way when I was trying to analyze the dump. I set the system up to allow me to crash it from the keyboard, triggered the hang, and forced the crash.
I sent Dell formatted dump information on the symlcsvc process, the subordinate thread (and its stack) that had sent the SPTD to the port driver, and the irpās (and their stacks) that had passed it to the miniport driver (there are technical inaccuracies in this sentence, for the sake of relative brevity).
Just less than sixteen hours later they called and said it looked like it was the drive.
Iām going to post this, and report on the drive later.
Congratulations on your patience! You deserve a medal.
Not that what you write in this message penetrates my understanding but I hope you do have it fixed and that it turns out to be the drive.
I have IDE, SCSI and SATA drives on my desktop and have experienced frustrations in the past but nothing like yours.
I presume you or someone has checked to see if the SPTD driver is the latest from whoever it came from?
Sorry to disturb. Great post Norwegian-
I know the SPTD driver only from Alcohol 120% and from Daemon Tools. Do you have these tools installed?
Cheerio
Lars
I'm sorry for having mislead some people. I was using SPTD only as an abbreviation for the ioctl Scsi-Pass-Through-Direct, which, as issued by symlcsvc, has been triggering my problem.
I have neither SPTD (the product) nor ASPI installed on the system.
An aside; I see that they've limited the time during which one can edit a post. Consequently I can no longer even try to fix the message body width problem on page 2 of the thread. I will try to get resampled versions of the images up on the host today, to improve their legibility. If the IE7 width problem is server-side, that might even fix it.
I think the secret on the width problem is to reduce the number of pixels in the image -- easy to do with some software including the free Irfanview -- down since websites only need something like 75 per inch and anything above that is overkill?
But you probably know more about this than I do.
The new drive.
So I sent Dell some formatted dump extracts. My intent was to show them that I had a bunch of data available, by sending them some samples; so, if they had somebody available who could interpret it, maybe we could get somewhere.
My support rep called the next morning and said that one of their technical experts had looked at the data I sent, and concluded that it was the drive. He said he would send a replacement and mentioned that they could not guarantee that it would be the same model, or even the same manufacturer.
Since I didn't talk to the expert, I had no feel for how confident they were that it was the drive. One of the possibilities had been the drive firmware (particularly as it's never been clear whether we were dealing with a flaw, or just an incompatibility), so I told my rep that I would prefer a different manufacturer if one was available.
The new drive and cable arrived the next day, over the noon hour. Not too shabby.
I had intended to approach this in a proper scientific manner. I was going to start by just replacing the cable.
But the replacement for my 146GB 10,000rpm Seagate SCSI drive was a 146GB 15,000rpm Fujitsu.
I decided that just replacing the cable represented an unacceptable risk<g>.
I was going to add the new drive and image the old one onto it, but I didn't have enough IDE-style power connectors available (most are SATA-style). So I installed the Fujitsu and de-cabled the Seagate, and used a Norton Save & Restore Recovery disk (free product plug) to restore an image backup from the Seagate onto the Fujitsu. Took 30 minutes.
No more logged errors; no more 3 minute system hangs, but...
I need to briefly reiterate my problem here. Symlcsvc contains some anti-piracy logic. Part of that involves getting some identifying information from the boot drive (I've yet to find out just what information). It tries to do that by issuing a SMART control to the device that contains the boot volume. SMART controls must target physical devices, such as \Device\Harddisk1\DR1. But, if you have a RAID controller, that string becomes a logical device reference. SMART controls issued to logical devices receive a "No way. You've got to be kidding. Shame on you for even asking." (that's 0xFU) response.
On my system, when that happens, symlcsvc goes in to snit mode (0xFU2) and tries to get the information using a Scsi-Pass-Through-Direct (SPTD) ioctl.
SPTDs can target anything, real or imagined; and are very difficult to stop because they almost don't really do anything, except pass the address of the actual control.
Their primary use appears to be to rip digital media, since they effectively bypass any copyright protection software.
With the Seagate drive installed, the SPTD usually failed. It would block access to the drive until it got timed-out after 60 seconds, effectively hanging the system (from the user perspective). When that happened, since it was in snit mode, symlcsvc would just send it again. It would quit after 3 failures (3 minutes of hung system). Symlcsvc never complained, never logged an error, never invalidated my Symantec software.
Other programs just had to wait, but Windows would usually log some paging timeouts.
The major purpose of the reiteration was to get us here. When the SPTD succeeded, it took between 5/10th and 7/10th of a second; which I thought was pretty impressive.
And now the but...
The SPTD always succeeds on the Fujitsu, but it takes between 5 and 7 seconds.
I've run logs and, generally speaking, everything else is faster on the Fujitsu.
It causes kind of a mini-hang; but it too short to trigger any paging timeouts, and it will only happen once per Windows session (I think).
I can live with it, but go figure...
Congratulations .... (I think) <s>
It a nice long time since I had to configure anything scsi but does the Fujitsu drive has its own scsi driver software? Does your scsi card have have a test/configuration utility -- my Adaptec comes with that.
I see my remaining scsi hard drive is throwing up regular error messages in Event VIewer and today my scsi scanner stopped working in XP but works fine from my VISTA ..... on a dual boot machine. Go figure!
I have used Norton products for years but the last few months have been awful. It started when Systemworks was about to expire and I upgraded on-line to Norton 360. It never worked. Their support team worked on my computer remotely for hours and finally gave up. They removed 360 and re-installed Systemworks (no price adjustment either). In any case it works EXCEPT for the fact I do not have virus protection for the other users on this computer (my daughters accounts). I have replied negatively to e-mails, surveys, phone calls (appointments to call me went ignored). It is unbelievable to be treated this poorly. Iāve ordered two laptops for my daughters as Christmas presents and itās highly unlikely I will use Norton products after this experience.
I'm sorry about your bad experience -- it should not work that way. Do you have any reference numbers from your contacts with Norton Support?
Do you mean you bought N360 (paid for it) and did not get a refund? If that is so we can help you get that underway.
Would you like help in getting N360 working on your present PC? Or even discussing whether NIS might be a better solution?
Let us know and there are a bunch of people here who can help.
The reference numbers are 490208602. They could never get 360 to work so they removed it from my computer and installed systemworks. It works fine for me but the sub-users on the same computer do not have virus protection. It's ironic I've gotten follow up e-mails twice to which I've responded the problem has not been solved, responded to a survey on service to no avail and received two phone calls, which resulted in two appointments to call back that evening which never took place.
Thanks for you offer to help.
Thanks for the feedback. I'll see if we can get a Symantec Staffer to pick this up and find out what went wrong and how to get you on the right track again.
<< They could never get 360 to work so they removed it from my computer and installed systemworks. It works fine for me but the sub-users on the same computer do not have virus protection. >>
Firstly, was that a copy of N360 that you paid for and now cannot get working? If so I'm sure something can be done about that.
Secondly, what version of Systemworks did they install -- Basic, Standard or Premier? And what year/Version? Basic has no AV at all but the others do and what is working for one user should be working for all on the same system -- what do you mean by "sub-user"? They are on the same PC but have their own desktop? If so I have both XP and VISTA set up on one PC with more than one user and all are protected although each operating system has to have its own installation.
Please let us know about these points.
Don't expect an immediate answer since it is just the end of a several day holiday and apart from catching up there are always new problems to be dealt with. But I'm sure we will get something sorted out.
I'm not really certain what version they installed and I'm not certain how to find out. Support called me at 10:00 PM one night and I turned my computer over to them. I fell asleep because it took so long. Apparently, they gave up at 1:00 AM. Their message said they couldn't get 360 to work, un-installed it and installed Systemworks since that is what I had previously. This all took place in August so you can see how long an ordeal this has been. I've kept all follow up e-mails for reference.
Yes, it was 360 premier I paid for.
In any case, I assume Systemworks is less expensive but I was never offered an adjustment. When I say "sub-user" it refers to my daughers account on the same computer. That only adds to the puzzlement since they are on the same computer. When using their accounts, the Norton symbol shows the red "X" and when you follow the instructions to fix the problem, nothing happens. My computer is a business Dell running XP professional and is only a year old.
Thanks again.
Thanks for all the details.
For Version information open up the main screen of the application and if it has a Help or Help & Support button click on that and see if there is About; click on that and it should tell you which kind of SystemWorks you have -- Basic / Standard / Premier and the version number which is in the form nn.nn.nn.nn. Since you say you have Norton AntiVirus that should rule out Basic.
Let's see what Symantec say on the refund or how to set you up with N360 if that is what you would like to achieve.
Understood about the sub-account. You should be fully protected on AntiVirus on that account as well as your main one but it sounds as if there is a setting that has not been set for that account.
<< the Norton symbol shows the red "X" and when you follow the instructions to fix the problem, nothing happens. >>
Does it give you an error message or tell you what the problem is?