|
Hi, I have a printer HP LaserJet 3005dn and I'm sure that my printer could print on both side based on the manual which is came with the printer. But when I successfully install the driver and i try to print both side, the printer just print on one site. There is no error message display. The printing run as normal but it just not print on both side whether i already select print on both side option. If anyone know the solution to fix the problem with please let me know. Thank in advance!!!
|
|
|
|
|
IF it's like the printers I use at work you need to set it on the client. Most Apps-File-Print-Properties-Look for duplex
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
Yes, this printer is attached to the client machine and I already set its software on the client machine. And that client machine could not print on both side whether he already selected the print on both side option. Any idea? Thank for your comment!!!
|
|
|
|
|
Either the driver is the wrong one, or it's bad, or the driver isn't configured correctly to know that the printer has a duplex option, or there's something wrong with the printer, or the printer really doesn't have a duplex option.
|
|
|
|
|
In the Printer Properties window, in the Device Settings tab, under Installable Options, is the Duplex Unit Installed?
|
|
|
|
|
Hi all,
I have a problem with the driver for my ethernet card. Everytime I do a warm start(that is restarting the pc) the MAC-address is showing up as 0's. But this doesnt happen with the cold start.
I am trying to track down on this problem. I am still not quite sure if this is a hardware/firmware problem or the driver problem.
I would be really glad if someone could tell me where does the network card normally read the MAC-address from. So that I can use the debugger to try and trace the problem.
Any help and advice on the subject would be great for a starting point.
Thanks
HM
|
|
|
|
|
The MAC address is normally hard-coded on the board. Mobile ethernet drivers will normally let you assign a MAC if you don't want to use the hard-coded one. It sounds like you've got a problem with the driver.
|
|
|
|
|
There is something flaky here, And I suspect its with the HW.
Reason being is that a warm boot or a cold boot still causes a driver unload. However, and this comes from personal experience, HW, because of capacitance, can maintain state over a warm boot.
There could be a reset HW funciton that the driver could do perhaps on an unload (MiniportHalt actually rather than MiniportUnload since you want to capture the HW going away event)) if you had acess to the driver code. If not, get on to the company that makes this and get them to look into it.
Morality is indistinguishable from social proscription
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
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
|
|
|
|
|
could you please let me know how i can write this address to the registry and later read it from there?
Thanks
|
|
|
|
|
Hey, come on, dont be so lazy, look in the DDK. 
Morality is indistinguishable from social proscription
|
|
|
|
|
... 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
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
