BSOD During Windows 7 OSD ndis.sys 0x000000D1

[senseless]

Hello everybody!

 

We have few models of notebooks in our organization. I've made a new image. Installed on one of the notebooks an OS with all software and registry keys need, Captured an image and successfully applied it into SCCM, after adding some drivers I started to use it. New notebooks models works fine with it and some of the old ones too, but few models after applying drivers at the last stage just showing BSOD 0x000000D1 problem with ndis.sys file . There's no dmp file created if I'll reboot a notebook and it won't load . After booting it says that the installation was interrupted please reboot and start it again. If I'll restore the previous image the OSD works fine! But the image was syspreped 3 times and there's no way I can update it. I couldn't find any info about ndis.sys it doesn't gives me any info about the driver that causes BSOD. Any ideas I can figure it out? On the task sequence I've tried to change driver installation options to install only best matched compatible drivers tried to check llimit driver matching to only consider drivers in selected categories , unchecked Do unattended installation of unsigned drivers and so on. I have an Acronis file of nonsyspreped image. I've checked smsts.logs it contains some errors but there's no any useful info as I think. Few logs are in attachment. Help.

 

Thanks.

dism.log

smsts.log

smsts-20130910-232440.log

[Rocket Man]

Had a model of a notebook before and they were an absolute pain as they too kept Blue screening. Before we had SCCM implemented we used WDS. Fortunately for us there was a crash dump file created and after using the MS debug tools we found it out to be an outdated graphics driver.

Check your graphics driver to see if there is any newer version for it and if there is try and create a driver specific package for that model and query it through WMI.

Having had some other BSODs over a period on different types of devices, I automatically check the graphics driver, and 9/10 times this is the cause in my cases. Maybe this is your problem also.

[senseless]

The problem only with 2 models Fujitsu A530 with Intel HD Graphics and Fujitsu SH531/GFX with 2 videocards Intel HD and Nvidia, but as far as I remember all threads about ndis.sys were with suggestions that the problem is with the network driver. On both notebooks I've disabled Wi-Fi adapters but it didn't help. So the problem could be in network driver. But which one, there's a lot of them? I'll try to update Intel HD video to a newest ones, and maybe Nvidia but later.

[Rocket Man]

Yes just after googling the ndis.sys also and see that it is relating to the network card. The above was with my own experiences.

 

On both notebooks I've disabled Wi-Fi adapters but it didn't help. So the problem could be in network driver. But which one, there's a lot of them?

 

I gather you have not packaged individual model specific driver packages for your devices. You are using a pool of drivers and then letting SCCM decide which one is compatible or best suited. If this is the case I would definitely think about creating a driver package for the problematic notebooks, this way it is much much easier to sort out the drivers if any are giving trouble.

 

You could try and disable some drivers to see if this helps you isolate which driver is causing the problem, but this will be a slow process considering you have numerous NIC drivers.

[senseless]

Yes, we are using a pool of drivers and few packages that were made as a pack of the Fujitsu, Lan and Lenovo notebooks that weren't made by me. All that stuff wasn't made totally be me, now I'm trying to figure out the best way to make all the new and old notebooks work fine. After migration to SCCM 2012 we will probably change the way driver packs are categorized. But I'm still don't understand why the the old image that was created few years ago and with updated software works fine on all the notebooks models?

You could try and disable some drivers to see if this helps you isolate which driver is causing the problem, but this will be a slow process considering you have numerous NIC drivers.

Thats the next step I would try, there aren't so much Realtek drivers added.

[Rocket Man]

 

But I'm still don't understand why the the old image that was created few years ago and with updated software works fine on all the notebooks models?

 

And have any drivers been added to SCCM since then?

As you are using a pool of drivers then SCCM may install any driver that is suitable, and if drivers have been added recently then maybe it's a newer version of driver that is causing the problems and not an undated driver!

 

When you move to CM2012 your better off creating driver packages for your notebooks/systems as there is less that can go wrong and only the drivers in the package will install and not any other one(s) that may be comaptible/suitable.

[senseless]

After new notebook models appeared I've added few network drivers from the original CD. A good idea about the new drivers. I've just disabled an old ones, If it doesn't help I'll try to disable the new ones and enable the old.

 

Of course you are right. After moving to SCCM 2012 we should rebuild the logical structure OSD works. Make few packages, and assign them to specific model. Each model is a specific package.

[senseless]

Still no luck. Disabled all the Realtek network drivers, added Driver Package with the drivers only for the specific model. And I'm getting the same BSOD. After notebook is installing drivers BSOD appears on the 99% of the drivers installation. Maybe there's a problem with the image?But what kind of problem could be if after sysprep all the drivers are being deleted? Because an old image is ok for any model, new one was created from one of the notebooks, captured and added to SCCM. Still can't get what am I doing wrong...

[Rocket Man]

It is better to capture your image from a VM not any physical machine as an image captured from a VM can do any model as no driver contamination has occurred. Then package your drivers for each model and attach them with WMI query to suit.

 

It would'nt be a huge task for you to capture a new image on a VM and import/distribute again, as you have created the driver package now. It is obviously the image that you captured from the notebook that is the problem. From my own experiences sysprep does not strip down drivers, as I remember when using WDS I had some custom images which were fully polished off with drivers etc... and once sysprep'd, captured and deployed again out to the model it was captured from all drivers were fine, so I feel that sysprep does not strip back drivers and your image is the problem as there are drivers in it that are not compatible with your other notebooks.

[senseless]

After I've made a new image and captured it from the virtual machine it is successfully applied to those notebooks. I think that it will be OK with new ones, even if I didn't test them. There's another issue with OS parameters after image the is applied but it is not so important as the previous problem. Thanks for the advice anyway.