Hardware & Devices

sharp8110-Dec-08 22:31

10-Dec-08 22:31

Thanks for the answers. Yeah, it could be the problem with the Hardware. I have access to the code. I dont know where I probabaly should set the breakpoint to check if its a HW or the Source code problem.

Whenever I run IPConfig after a warm boot I see MAC-address as 0.0.0.0.0.0

Can you explain the solution a bit more detailed exactly how windows reads and initializes the MAC-Address for the network card?

Thanks and Regards
Sharp

fat_boy10-Dec-08 22:47

10-Dec-08 22:47

The MAC address woulod normally be read ff the card, but could be overridden by the code.

What you have ia an OID to get the mac address (OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. Look for these in the OID handler (thi8s will be declared in the DriverEntry funciton in the MinioprtCharacteristics structure.)

Now, look for the data the driver is returning for this OID and find where it is obtained. You now have the point at which the HW is failing to respind with the correct data.

So, since this is a warm boot issue only, I would do a HW reset at the beginning of the MiniportInitialise function (yours will be called somethiung else but it will also be declared in the MiniportCharacteristics structure).

This of course is if the HW has some kind of a rest ability. If not you are going to have to make a workaround.

If the data the driver gets form the card is valid, ie it isnt zero, then store that data in the registry under the devices config ares (look at NdisOpenConfiguration() ).

Then, next time you do a warm boot and read a zero address from the card your driver can go to the configuration area and retrieve the real address and use that.

If this is difficult for you to do then I can offer my services as a consultant and do the work instead.

Morality is indistinguishable from social proscription

sharp8110-Dec-08 23:31

10-Dec-08 23:31

Thanks for the reply again. I am not very familiar with using the debugging tool to set bp and check where the problem is happening. It would be great if you let me know how I can use the windebugger to check for the OID handler.

fat_boy10-Dec-08 23:35

10-Dec-08 23:35

You need to get hold of a DDk (or as they are now called WDK) and go through the section on setting up a kernel debug session. Its a little trickky, depending on the OS involved. Or gogle for information on this, osr-online are a good source for info on kernel topics.

Morality is indistinguishable from social proscription

sharp8110-Dec-08 23:44

10-Dec-08 23:44

I have setup all the environment with WDK and Windebugger. My next step is to start debugging the code for the network card. This is where I have problems as I dont quite get it where to analyse the breakpoints.

fat_boy11-Dec-08 0:42

11-Dec-08 0:42

OK, so you need to run a debug bersion of the driver, build one using the WDK.

Then set the symbol path in WinDbg to the location of the pdb for your driver.

Set the code path to the location of your drivers source files.

Also set source mode on in WinDbg (Off the Debug menu).

You also need to disable the ethernet card in Device Manager. Why? Well. if you put a BSOD in the code and its set to autostart you will never get the machine up and running again short of booting in safe mode.

You can use .kdfiles command to cause a dynamic driver load from the nost PC to the target PC.

Then when you enable the device in DeviceManager the driver gets copied over. This is quicker than copying it over via a USB stick and gets round Windows File Protection.

Since this error occurs during initialise you want to hard code a breakpoint in MiniportInitialise().

You should also be able to repro the issue with a quick disable-enable in device manager since the device will be depowered for a short time.

If this fails then you need to cath the error after a warm boot, in which case you need the device enqabled in DevoceManager and hope you dont leave any BSODs in the code.

When the machine breaks you can make sure the pdbs are loaded for you device. Look in Debug-Modules in WinDbg. If it doesnt show a pdb loaded for your driver then highlight it and do a reload.

Then by doing a couple of step throughs (F10) the debugger wil load the relevant code and highlight the line you are using.

Morality is indistinguishable from social proscription

sharp8111-Dec-08 2:41

11-Dec-08 2:41

Now i found out where exactly the problem is in the code. Its taking the MAC-Address as 0's in the driver initialisation with memcpy and OID parameters.
How can I do a HW reset so that I can check if that's where the problem lies.

Thanks.

fat_boy15-Dec-08 22:55

15-Dec-08 22:55

sharp81 wrote:
Its taking the MAC-Address as 0's in the driver initialisation with memcpy and OID parameters

At some stage the code should get the MAC address off the card. Search the code for any place where the variable that holds the MAC address gets written to.

sharp81 wrote:
How can I do a HW reset so that I can check if that's where the problem lies

That will be device dependent but would probably involove a write of a byte to a port.

Morality is indistinguishable from social proscription

sharp8114-Dec-08 6:14

14-Dec-08 6:14

I want to check if the problem is actually lying in the firmware or the software. Do you know how I can get traces from the firmware to check where the problem might be lying. I know there are some trace tools that I can couple with Windbg but dont know if it can do a firmware trace.

Thanks for your help again.

Sharp

fat_boy15-Dec-08 22:56

15-Dec-08 22:56

sharp81 wrote:
how I can get traces from the firmware

Again that is device dependent. You might need an external bit of HW that plugs into the card, or there could be some SW that can do it. I dont know, but windbgg wont be able to onits own.

Morality is indistinguishable from social proscription

sharp817-Jan-09 23:00

7-Jan-09 23:00

Thanks again. I think here the firmware is not resetting on a warm boot. But actually we dont want a firmware reset either. Could this also be a synchronisation problem? When I do a cold reset and then do a disable and enable of the device it still works. I guess it should be pretty much the same when we warm boot or?

fat_boy8-Jan-09 0:05

8-Jan-09 0:05

Best thing is to read the address of the FW. If it returns a valid address, it was a cold boot, so the driver can then write that address somewhere usefull in the registry. Then, when it next boots, if it reads a zero off the FW it can get the address from the registry and use that.

Morality is indistinguishable from social proscription

sharp818-Jan-09 0:54

8-Jan-09 0:54

could you please let me know how i can write this address to the registry and later read it from there?

Thanks

fat_boy8-Jan-09 1:08

8-Jan-09 1:08

Hey, come on, dont be so lazy, look in the DDK. Smile | :)

Morality is indistinguishable from social proscription

sharp818-Jan-09 5:28

8-Jan-09 5:28

... yeah, i guess you are right ... i will do some reading and try to find the solution.
Btw I would prefer rather than spoofing the MAC to actually figure out the exact location of the problem.
In my case when I try to enable and disable the driver after a cold boot I still see the correct MAC but with the warm start its still the same problem no reaction at all. I dont how the driver initializes in case of disabling and enabling but isnt it similar to the way its warm booted?

What would be your suggestion without having to use the registry to find the error?

And thanks for all the support

fat_boy8-Jan-09 5:50

8-Jan-09 5:50

Well, it IS a FW/HW problem. Its coming out of a warm boot into some kind of bad state. Probably due to capacitance on the card still. You either need to have some clear down HW so the caps get discharged or have a HW reset feature in FW.

But, you can use the approach I mentioned to over come this since you arent spoofing the addresss, merely remembering it from a cold boot where the driver can read it correctly.

Morality is indistinguishable from social proscription

sharp818-Jan-09 23:28

8-Jan-09 23:28

I tried a firmware trace and it tries to get the multicast address but with the wrong values. That's the reason I wonder if it is either a sync problem or if this could do something with the SW. How can I make sure it is a FW/HW problem?

fat_boy9-Jan-09 2:52

9-Jan-09 2:52

If your driver reads the address off a particular port on the card and it gets a zero after a warm boot then its a HW/FW issue.

And I assume you have verified this in windbg or some such?

Morality is indistinguishable from social proscription

sharp819-Jan-09 3:09

9-Jan-09 3:09

I tried to debug in Windbg for the error. I tried to set the bp on the driver initialize function. I think it did go through the driver init but still obtained the 0's.
I will do the debug again and provide you the results. But how could it work when I disable and enable the driver in the device manager? Isnt it the same as a warm start?

fat_boy9-Jan-09 4:12

9-Jan-09 4:12

sharp81 wrote:
But how could it work when I disable and enable the driver in the device manager? Isnt it the same as a warm start?

I guess not. DOnt forget a warm boot leaves the device depowerted for a very short time, far shorter than you can click disable and enable in device manager

Morality is indistinguishable from social proscription

sharp819-Jan-09 4:36

9-Jan-09 4:36

So when i do a warm boot and then disable and enable in device manager it doesnt work becoz at this point the device already has a wrong MAC-address. One more test I tried out was to disable the device in device manager and enable it again after a warm start but it still doesnt work on that case. In windbg I used the locals to check for the MAC-address value. Is this the only place to do this or what other options would you recommend to check for the MAC-Address changes?

Thanks

fat_boy9-Jan-09 4:58

9-Jan-09 4:58

Does the device depower when disabled in device manager?

Anyway, the best solution is the one I have suggested. Read the MAC address and if its not zero, store it in the registry. Of it is zero, then get it from the registry.

Morality is indistinguishable from social proscription

sharp819-Jan-09 5:06

9-Jan-09 5:06

I think it does not depower but i am not totally sure either. Becoz if it does depower then it should work just like a cold start. So I guess it doesnt depower and just takes the value available. Though I could see from the debugger that on enabling in device manager it starts the driver initialization again.

You mentioned with a cold start it depowers very fast and is back up again. So why do you think its not a sync problem?

I think i like your solution but the thing I have to make sure changing the code is that there arent any errors. Are there any code snippets for reading and writing Address to registry?

fat_boy9-Jan-09 5:10

9-Jan-09 5:10

sharp81 wrote:
I think it does not depower but i am not totally sure either. Becoz if it does depower then it should work just like a cold start.

Yes. Unless some other perverse logic is involved, which is possible.

sharp81 wrote:
Though I could see from the debugger that on enabling in device manager it starts the driver initialization again

It always will.

sharp81 wrote:
I think i like your solution but the thing I have to make sure changing the code is that there arent any errors. Are there any code snippets for reading and writing Address to registry?

If you want to be a kernel programmer you are gong to roll your sleves up and get your hands dirty. The DDK might have some samples, but better than to cut and paste, whcih can create all kinds of errors, just read the docs and go for it.

Since its Ethernet, and hence Ndis, look at NdisOpenConfiguration (or NdisOpenConfigurationEx for an ndis 6 driver (ie for vista only))

Its quite simple. You call this from MiniportInitialise (you cant call it at any other time, you get a BSOD if you do) andf then NdisReadConfiguration.

Morality is indistinguishable from social proscription

sharp8112-Jan-09 23:19