Re[2]: How to simulate a clean machine for KMDF1.1 installation?

Hello Mark,

RM> The simplest answer is to set up your test lab so you can do clean OS
RM> installs with a minimum of hassle and wasted time. For example do a
RM> clean install once for each OS release and ghost an image and archive
RM> it. Re-ghost anytime you need a clean test environment.

much better for USB devices or none hardware devices is a VM with
VMWare. Very short time from snapshoot to next try :slight_smile:

elli

RM> -----Original Message-----
RM> From: xxxxx@lists.osr.com
RM> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@careful.co.uk
RM> Sent: Tuesday, October 10, 2006 9:56 AM
RM> To: Windows System Software Devs Interest List
RM> Subject: [ntdev] How to simulate a clean machine for KMDF1.1
RM> installation?

RM> I’ve had installation problems with my KMDF1.1 based drivers two or
RM> three times recently: the drivers install fine on my target machine, but
RM> fail on a machine that has never had a KMDF driver installed.

RM> The problem in each case is because I’ve modified the .inf file
RM> incorrectly and the coinstaller fails to install (The last time was when
RM> I tried to alter it from installing a KMDF filter over a KMDF function
RM> driver to installing the filter over one of two different function
RM> drivers). I use ChkInf but, even on the .inf files that work, it
RM> complains that the coinstaller sections are not referenced so there
RM> isn’t an easy way to validate the changes - except by trying it on a
RM> clean machine.

RM> So how can I simulate a clean installation? What services do I need to
RM> uninstall, what files to delete etc.?

RM> All suggestions gratefully accepted.

RM> Don

RM> —
RM> Questions? First check the Kernel Driver FAQ at
RM> http://www.osronline.com/article.cfm?id=256

RM> To unsubscribe, visit the List Server section of OSR Online at
RM> http://www.osronline.com/page.cfm?name=ListServer

RM> —
RM> Questions? First check the Kernel Driver FAQ at
RM> http://www.osronline.com/article.cfm?id=256

RM> To unsubscribe, visit the List Server section of OSR Online
RM> at http://www.osronline.com/page.cfm?name=ListServer

–
Best regards,
Mailing mailto:xxxxx@ellisoft.de

Indeed - the VM solution is quite simple but the supported hardware is
also quite limited.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mailing Lists
Sent: Tuesday, October 10, 2006 4:35 PM
To: Windows System Software Devs Interest List
Subject: Re[2]: [ntdev] How to simulate a clean machine for KMDF1.1
installation?

Hello Mark,

RM> The simplest answer is to set up your test lab so you can do clean
OS
RM> installs with a minimum of hassle and wasted time. For example do a
RM> clean install once for each OS release and ghost an image and
archive
RM> it. Re-ghost anytime you need a clean test environment.

much better for USB devices or none hardware devices is a VM with
VMWare. Very short time from snapshoot to next try :slight_smile:

elli

RM> -----Original Message-----
RM> From: xxxxx@lists.osr.com
RM> [mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@careful.co.uk
RM> Sent: Tuesday, October 10, 2006 9:56 AM
RM> To: Windows System Software Devs Interest List
RM> Subject: [ntdev] How to simulate a clean machine for KMDF1.1
RM> installation?

RM> I’ve had installation problems with my KMDF1.1 based drivers two or
RM> three times recently: the drivers install fine on my target machine,
but
RM> fail on a machine that has never had a KMDF driver installed.

RM> The problem in each case is because I’ve modified the .inf file
RM> incorrectly and the coinstaller fails to install (The last time was
when
RM> I tried to alter it from installing a KMDF filter over a KMDF
function
RM> driver to installing the filter over one of two different function
RM> drivers). I use ChkInf but, even on the .inf files that work, it
RM> complains that the coinstaller sections are not referenced so there
RM> isn’t an easy way to validate the changes - except by trying it on a
RM> clean machine.

RM> So how can I simulate a clean installation? What services do I need
to
RM> uninstall, what files to delete etc.?

RM> All suggestions gratefully accepted.

RM> Don

RM> —
RM> Questions? First check the Kernel Driver FAQ at
RM> http://www.osronline.com/article.cfm?id=256

RM> To unsubscribe, visit the List Server section of OSR Online at
RM> http://www.osronline.com/page.cfm?name=ListServer

RM> —
RM> Questions? First check the Kernel Driver FAQ at
RM> http://www.osronline.com/article.cfm?id=256

RM> To unsubscribe, visit the List Server section of OSR Online
RM> at http://www.osronline.com/page.cfm?name=ListServer

–
Best regards,
Mailing mailto:xxxxx@ellisoft.de


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

The trouble with SRP is that the older ones go away after a while.
There is a limit for how much disk space SRPs are allowed to use and
when that limit is reached, Windows starts deleting them oldest first.
AFAIK, there is no way to tell Windows to keep one SRP forever. If you
are only going back one SRP and there aren’t a lot of reboots or
driver installs in between, you’re probably OK.

Beverly

On 10/10/06, Don Ward wrote:
> Hello Mark
>
> > The simplest answer is to set up your test lab so you can do clean OS
> > installs with a minimum of hassle and wasted time. For example do a
> > clean install once for each OS release and ghost an image and archive
> > it. Re-ghost anytime you need a clean test environment.
> >
>
> You’re right. It is probably the simplest, although perhaps not the quickest.
> I don’t really want to restore the O/S every time I want to try out my latest
> tweak to an inf file that isn’t working. But if that’s the only way …
>
> BTW. Did you mean Norton Ghost? or were you using “Ghost” as a generic term for
> disk imaging and restore software? If the former, it looks as though it only
> works for Win2000 and XP targets.
>
> However, your suggestion made me think that perhaps I could do what I wanted
> with system restore points. Presumably, going back to an SRP prior to the first
> ever installation of a KMDF driver would remove all traces of it.
>
> I still wish I could just uninstall it though (and be guaranteed to get rid of
> all of the background stuff that the coinstaller puts on my system).
>
> Thanks.
>
> Don
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

> I don’t really want to restore the O/S every time I want to try out my

latest
tweak to an inf file that isn’t working. But if that’s the only way …

BTW. Did you mean Norton Ghost? or were you using “Ghost” as a generic
term for
disk imaging and restore software? If the former, it looks as though it
only
works for Win2000 and XP targets.

The last few version of the WDK have the Microsoft ImageX utility. ImageX is
a utility to write a volume to a file or restore an image file to a volume.
What I really like about ImageX is its pretty fast, it’s a command line
program (scriptable, although a COM interface would be nice) that doesn’t
need a zillion DLL’s, and I can run if from Windows (because I generally
connect via remote desktop).

I regularly restore a clean OS image for my target system (about every 10
days currently).

I setup my target machine like this:

Split the disk into a bunch of 10 GByte partitions (I get 8 partitions on my
80 GByte drive). I am currently NOT installing an OS on the C: partition. I
installed a utility copy of W2k3 on d:, which I use for imaging operations
on the other volumes. On the other partitions, I have installed a range of
OS flavors 32-bit/64-bit/checked/free, and before I “contaminated” them with
my drivers, I booted the utility OS and ran in ImageX volume snapshot into a
partition with no OS.

I can now boot to the utility OS copy and do an ImageX restore in about 5
minutes, and I get a nice fresh copy of the target OS. It would probably be
possible to write a little script that automatically did the alternative OS
reboot, and the restore, and the boot to the target OS, although I’m also
looking to see of DTM can do all this inside a driver testing framework.

The image files I have also went through a couple iterations, as over time I
learned how I wanted my “clean” OS to be configured. When restored, they
come up all activated, with things like the remote desktop enabled and all
normal drivers installed. I also set driver signing to ignore, turned of
Windows update check for drivers, and turned off the shutdown reason
tracker. If I find I keep setting something after every restore, I just load
the clean image, boot that OS, adjust it to my liking, boot the utility OS,
and make a new image file.

My machines are also all far away in a machine room, so I have an EMS
console hooked up via Hyperterminal or a serial port terminal server. I can
also remote power cycle, but with EMS available, and the kernel debugger
also available, it’s pretty rare that I have to power cycle (although it
still sometimes is needed, like if I flash new firmware in a device).

I have not yet installed Vista, and since I’m working on server products,
will probably just jump to Longhorn beta’s. I believe this will complicate
boot OS selection some, but believe I will still be able to use an EMS
console to select between Longhorn or older w2k3 flavors. Writing scripts
that can automatically select between w2k3/longhorn may be interesting.

Does anybody know if the Vista/Longhorn bootcfg program will run from w2k3,
to select the default boot when I switch back and forth between Longhorn and
W2k3?

  • Jan