I'm suffering brainlock at the moment. I have an entry in my environment variables in XP defining the NMSYMPATH variable. It is pointing to the softice directory. I can't remember if it was something I added for cygwin or whether it is a legit softice variable.

A search on Google or through the RCE search facility reveals nada.

Numega Symbol Path ?

Yeah...I gathered that much. I have never seen it referenced anywhere. In winice.dat, you have to indicate if you want symbols on or not (i.e. NTSYMBOLS=ON) but I have never seen instructions to add anything about NMSYMPATH to the XP environment.

I also have 'LOAD' instructions in my winice.dat which point to the NMS file directory. I just can remember entering an NMSYMPATH in the XP environment, especially one pointing to the softice directory.

You didn't. Softice did during installation. Feel the love.

Kayaker...thanks for the heads up. I'm wondering why it refers to the softice directory, however. Is it because symserver is there? I have my nms files elsehwere and I'm wondering if I should direct the environment to that directory?

No I think that's correct. My NMSYMPATH points to
C:\...\DS32\SoftICE
which is the location, dare I say Path, of nmsym.exe (run in console mode - nmsym /help)

Other symbol path information is kept in the registry as well as the nmsymret.ini file in the Symbol Retriever folder, which should point to your nmsout directory.

You still having problems translating symbols?

Didn't even know about the ini file for symserver. Took a look at it and I see my nms file directory but the actual symbol directory is missing an 's' in symbols. Seems to find it ok. Can you confirm that yours has a missing 's', if applicable?

I'm still having the occasional problem with symbols but I have enough good nms files to get by. I make them in IDA if I really need them, since IDA always finds the pdb files. I haven't fired up softice for a week or so because I'm still trying to figure out what's going on with my SATA controller that I described in 'off topic'.

I'm trying to find a way to examine the SATA driver as it enumerates the registry, but it's a boot time driver. I was playing with EzDriverIntstaller and it loads the same driver with a question mark beside it. I was wondering what would happen if I uninstalled the actual driver and re-installed it with EzDriverInstaller under softice with a breakpoint on the registry enumeration function, or elsewhere. I'd like to watch the driver loading to see how it determines what UDMA transfer mode to implement. I'm still very green with drivers, however, and a bit intimidated.

My problems may be deeper than that. It appears Intel compromised when it introduced the ICH4 and ICH5 hub controllers. To implement SATA with PATA, it left several combinations of each up to the OS. In other words, you could use some PATA and SATA but not all of the available controllers at once. On my system, if I delete the device attached to SATA controller channel 0, using the Silicon Image SATA configuration utility, it actually deletes the hard drive attached to PATA controller 0, channel 1. That actually makes sense given the arrangement Intel provided, if the OS was not implemented correctly.

Here's a bit of parting humour. I used the Maxtor hard drive utility to test my hard drive. It flagged the drive with an 'unknown' error. I used the Seagate Seatools utility (they have taken over Maxtor) and it did the same, advising me to urgently contact tech support with an obfuscated error code. Noting that I had the Western Digital Lifeguard Diagnostics utility loaded, I tried it. It not only identified the error as a bad sector, it fixed it. My next hard drive will therefore be a Western Digital drive.

Not quite sure, both my directories are default, c:/nmsout for the NMS files and c:/symserver for the raw pdb symbols. The only "symbols" word in my ini file is in the msdl/microsoft/download/symbols path.

I've done some work on the problem with no luck. For instance, I got a fresh copy of symsrvr.exe with fresh support files from the Msoft tools directory. I noted that symserver was retrieving the pdb files from my local symbol directory, so I renamed the kernel32.pdb files, forcing it to call out to Msoft for a fresh copy, which it installed in my symbols directory. When I checked the nms file it created, the file had no names in it and was only 40k long, yet the pdb file has all the names in it. In fact, I used the same pdb file in IDA to make a good nms file with all the names.

I don't know what's going on.

That's weird. The correct size of kernel32.nms, as translated by Symrtrvr.exe, should be about 238KB. If I translate the kernel32.pdb symbol file manually using Nmsym.exe it's about 40KB, the same as you're (incorrectly) getting.

You can also translate a symbol file with Loader32.exe in command line mode (see help file). In that case I also get an incomplete nms file of 40KB.


I decided to look at Symrtrvr.exe as it's translating the symbol files from pdb->nms. Internally it calls Nmsym.exe with CreateProcess using a CommandLine. I set a breakpoint at that point and looked at the command line string. Here it is:

/translate C:\symserver\kernel32.pdb\072FF0EB54D24DFAAE9D13885486EE092\kernel32.dll /output:c:\nmsout\kernel32.nms


This makes perfect sense, except, notice the ref is *DLL* instead of the actual file extension *PDB*. Other refs are similar, win32k.pdb is written as win32k.sys, ntoskrnl.pdb is written as ntoskrnl.exe. Odd that.

So then I used that exact command string with Nmsym.exe manually from a command prompt. When written as "DLL" it gave the expected Windows error "file not found". When written as "PDB" the translation proceeded, but only gave the 40KB version.

That's what's weird. When run under Symrtrvr.exe, the command line for nmsym.exe is intuitively incorrect, but gives the correct NMS result. When run manually, nmsym.exe only works with the intuitively correct command line syntax, but gives the incorrect NMS.

I dunno, there must be further steps in the translation that aren't obvious.

The really weird thing is:

a)it used to work with the same setup.
b)it still does work...occasionally.

I'm up to my butt in alligators right now and don't have time to worry about the nms files, since I can get by with the IDA plug i2s, or whatever it's called.. I veered off in several direction trying to solve my SATA problem and ran smack-dab into the NET framework. Silicon image provides two config utilities, one in JAVA and the other in NET.

I d/l'd some files to look at the NET exe and one reported not being able to find a certain VC file in a directory under winxp/assembly called GAC_MSIL. When you look at the assembly directory from a CMD prompt, all the files are there. When you look under Windows there nothing there...the entire directory is empty.

I have to pause here in frustration wondering what the heck Microsoft are up to. Why the heck would they hide a directory like a rootkit would hide it? Honestly, sometimes the thinking that comes out of Msoft is little more than childishness. Why would they set up a directory so another application can't find it?

Now I am scouring the net (no pun) trying to find out if I can unhide a directory. Of course, the Net is loaded with wanabees trying to offer inane advice. Anyone using Windoze figures out in the first week that Msoft hides system files and you have to turn the feature on. So, when you want to find out how to turn on a really hidden directory, you have to wade through all the obvious crap from the wanabees.

Something like this perhaps?

attrib *.* -s -h -a /S /D

That's what I use to unhide

"C:\Documents and Settings\NOYB\Local Settings\Temporary Internet Files\Content.IE5"

You can remove the UICLSID={ string from
\Temporary Internet Files\desktop.ini
leaving only the
[.ShellClassInfo]
to make the change permanent for this particular case

I found that trick on the net somewhere.

Yeah...thanks Kayaker. I'm an old DOS hand from the Rio Grande. I tried the attrib trick in a DOS box, but it wouldn't take. Then I tried it in Start/Run and it did work, but only for the first level of sub-directories. I could not open the other sub-directories even though their icons were available. I tried attrib on all of them.

I freaked myself along the way. I use a replacement file manager for Explorer because I think it's a fossil, especially with it's single-pane operation. I mean, how does anyone drag and drop files with one window? I've seen people copy and paste but it's a royal pain. Anyway, I was diddling with a filter on my file manager and I switched off all the files in the directories. All you could see were directories, no files.

Turned out to be something I recalled from way back. On this manager, you can select the attributes in a windows with a radio box. The trick is that the radio box has 3 positions: on, off and in-between...kind of greyed out but operational. That's the position the boxes have to be in, so I got my files back when I remembered that.