cluberti

If you're using Vista or Win7, look in the \System32 folder for the Printing_Admin_Scripts folder. There are vbs scripts there to do printer management, so you no longer have to use rundll32 to install drivers, queues, etc.

%windir%\logs\CBS\

Only the CBS log would show this.

Can you run imagex /info <.wim file> against that WIM to see what is actually in there? Assuming you have a WIM with only Enterprise, it's not possible to install Business from it. Sounds like either an answer file issue, or an incorrect image # used in the WIM file.

Potentially - can you get the CBS logs from one of these sysprep runs? What specifically is happening when OOBE runs at this point is it's extracting all of the language packs you've added, and then adding the servicing/WinSXS binaries to the system. French being a fully-localized version of a language pack (versus en-ca, which is just CA on top of the base EN) takes a lot longer compared to the others. The more language packs you add, the longer this takes (and remember, binaries for x64 are at least twice as large as x86, because they contain both amd64 and wow64 versions of the files). Taking 35 - 40 minutes seems a bit excessive though, so if you could repro one more time and get the setup*.log files as well as the \Panther directory and CBS.log, that would be useful (the CBS log might be very interesting).

No, drivers would indeed not cause this particular delay. The only other times I've seen this, redoing this with an image without language packs added removed the problem. This is sysprep running oobe/setup, which is configuring OOBE and languages. It's taking all of it's time there, but as to why, I couldn't say for sure - I can only say that the other times I've seen this it's been problems with language packs added to the base image.

According to Dell, the Optiplex 980 is using the Intel Q57 chipset, meaning it most likely has an Intel 82578DM network chip. Do you have drivers specifically for that in your drivers folder? You really only want to integrate absolutely necessary drivers into a WinPE WIM.

Again, that's wonderful to know. Without data, I cannot help you, and you seem adamant in not doing something basic like taking a network trace for a potential network printing issue. As a network admin, you'd think you'd have done this already and would have had the data asked for. Good luck - I'll leave you to others to assist, but I'm done.

I can already see that this is going to need to be in the Programming section - moved.

Question - how many language packs are installed in this image? I've only ever seen the call to "Launching [C:\Windows\system32\oobe\setup.exe]..." from windeploy take that long when an image had a large number of language interfaces installed...

Microsoft injects drivers for common hardware, but only for vendors that supply signed (and tested) drivers to Microsoft for inclusion, from what I understand. They can't just go out and redistribute other vendors' drivers at will.

That's great, but we still need a network trace to tell you what did (or did not) happen over the wire when you went to use the non-working printer and subsequently got that error.

Without a simultaneous network trace from both client using the printer and server hosting the print queue/printer, it's hard to say. All we know is that the connection failed - the network trace would tell us if it's a network problem or not.

There isn't one, the API isn't public. You could watch it with a debugger and see if you can write some code to emulate it, but there's no public way (other than the IE8 UI) to accomplish this.

Please post nlite questions in the nlite section. Moved.

Please post nlite questions in the nlite section. Moved.

Considering the B4200 is only emulating PCL6 anyway, you're probably fine with the inbox driver. Would be worth installing Windows 7 and trying these older printers out, to see if they will print using a compatible inbox driver or a generic one.

Windows 7 has Samsung ML drivers inbox, but no 5xxx drivers at all. A quick look on the Samsung site for that model also says there were no Vista drivers, so unless you can get it to work with older 4xxx drivers (also included with Win7) or a generic driver, you're out of luck.

Win7 runs fine on an old P4 2.4GHz machine I've got here, although it is a bit slow to get to the desktop. Once it's up and running, though, it's fine (2GB of RAM and an nvidia 8800GT help), and considering I reboot it once in a blue moon (it is pretty snappy resuming from sleep) it's just not a problem.

Hrm - this file isn't timestamped at all, which I guess is potentially expected. It is odd that it keeps going back and installing/removing the video driver for an Intel G41 chipset though, over and over, without logging ANY of the UMDF CBS logging that would generally be logged in between. This is a mystery.

In looking at the dump, there are two possibilities for this: // Here's the stack, showing what appears to be Winlogon.exe attempting to display text - // note there's a module that was injected when the Semaphore lock was requested: kd> kn # ChildEBP RetAddr 00 f3e1fba8 80465a81 nt!KiDispatchException+0x30e 01 f3e1fc10 8046606b nt!CommonDispatchException+0x4d 02 f3e1fc10 804145da nt!KiTrap03+0x97 03 f3e1fc88 f3e1fce8 nt!ExTryToAcquireResourceExclusiveLite WARNING: Frame IP not in any known module. Following frames may be wrong. 04 f3e1fc8c a00b14bd 0xf3e1fce8 05 f3e1fc98 a00be963 win32k!GreAcquireSemaphore+0x19 06 f3e1fc9c a000c650 win32k!DEVLOCKOBJ::vLock+0x20 07 f3e1fce8 a0020aba win32k!DC::bSetDefaultRegion+0x4c 08 f3e1fd10 a001b529 win32k!GreCreateDisplayDC+0x135 09 f3e1fd28 a001e12d win32k!GreCreateCompatibleDC+0x24 0a f3e1fd30 bffa0f8f win32k!NtGdiCreateCompatibleDC+0x9 0b f3e1fe14 77e5a17d safemon+0x2f8f 0c 00000000 00000000 USER32!DrawTextExWorker+0x344 In looking at the raw stack, what you see on the stack where the function is missing is a Win32K HANDLELOCK::vLockHandle call, a User32 StaticWndProcWorker call (meaning there's a hook on the WndProc this is using, so someone is going to inject themselves), and then vpc_s3 injects itself. Afterwards there's a callback to Win32K, which is supposed to use the handle it acquired in the GreAcquireSemaphore call to actually call the ExTryToAcquireResourceExclusiveLite. However, it appears the handle is NULL, thus causing the problem. Like I said, this has two potential culprits - either vpc_s3.sys, or safemon.sys, although I suspect the Connectix VirtualPC driver (vpc-s3.sys) more than I suspect the System Security Monitor driver (especially considering vpc-s3.sys is the Virtual PC virtual video driver miniport), but nothing would surprise me with the System Security Monitor suite either. It's your choice how you want to proceed - one of these two (or both) are causing the problem, so you're going to have to decide which to keep, which to update, etc: kd> lmvm vpc_s3 start end module name f3c90000 f3c9f220 vpc_s3 (deferred) Image path: \SystemRoot\System32\DRIVERS\vpc-s3.sys Image name: vpc-s3.sys Timestamp: Thu May 16 14:00:20 2002 (3CE3F3B4) CheckSum: 0001A38A ImageSize: 0000F220 File version: 4.0.2.1 Product version: 4.0.2.1 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.4 Driver File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Connectix Corporation ProductName: Connectix Virtual PC InternalName: vpc-s3.sys OriginalFilename: vpc-s3.sys ProductVersion: 4.02 FileVersion: 4.02 FileDescription: Virtual PC S3 Miniport Driver LegalCopyright: Copyright (C) Connectix Corporation 1999-2001 kd> lmvm safemon start end module name bff9e000 bffc0200 safemon (no symbols) Loaded symbol image file: safemon.sys Image path: safemon.sys Image name: safemon.sys Timestamp: Fri Oct 27 10:52:01 2006 (45421D11) CheckSum: 00029436 ImageSize: 00022200 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 I would suggest upgrading to Virtual PC 2004 SP1 anyway, for what it's worth. Connectix 4.x versions were buggy, as was the original VPC 2004 release, but SP1 and 2007 were rock-solid.

Yes, get an xperf, and run it for a few minutes while the CPU is under load like that. Now that you've cleaned it up, I'd do simple things like defrag the disk to make sure all of that is OK as well before gathering the trace, of course. Please don't go to geek squad - this is not something they're going to be able to fix for you unless you get really lucky and find a tech who a. knows what he's doing and b. hates himself enough to be working for geek squad. Otherwise, you're going to find a salesman (or woman) in a tie who can boot a CD and run some utilities (most of which you have already done, I believe).

Good point - updated.

#1 - yes, it's possible. Just do a search for that .dll name on Google to get some results. I am going to suggest at this point you scan that system offline, with an offline virus scanner, rather than online, just to be safe. #2 - So Admins own the folder, SYSTEM has full control, and everyone else has read. It's no wonder you can't delete it!

#1 - You have an svchost process consuming CPU that appears to be a virus infection (svchost PID 1980). It's loading a binary called rswin_3725.dll, which is not an MS binary but appears to be some sort of Akamai service .dll. That's pretty suspicious, honestly. #2 - Run the command powershell -command "Get-ChildItem <path to folder> -recurse | Get-Acl | format-table -wrap" (replacing <path to folder> with the actual folder path on your machine) and paste the screen output here.