Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


cluberti

Patron
  • Content Count

    11,044
  • Donations

    $0.00 
  • Joined

  • Last visited

Posts posted by cluberti


  1. Smartscreen is extended when run in Win8 to verify the authenticity of apps or programs you install or sideload, which is where it differs from IE9 on Win7 (only reports on downloaded files via IE if there's an attempt to install it).


  2. For your 1st question, certutil works and is designed for something like this assuming you have the certificate to install:

    http://blogs.msdn.com/b/steverac/archive/2009/07/09/adding-certificates-to-the-local-certificates-store-and-setting-local-policy-using-a-command-line-system-center-updates-publisher-example.aspx

    For the 2nd issue, it sounds like your NAS doesn't understand or isn't configured to accept secure SMB signing on SMB connections. You might want to see if your NAS actually supports this and see if it can be enabled. Otherwise, you need to set this in WinPE 4.x (or use WinPE 3.x and the WAIK in MDT instead to deploy Win8 - it's slower, but it doesn't have this enabled by default). Note that your Win8 installs are going to have a problem with the NAS too unless you run this there or set the RequireSecureNegotiate value to 0 in the LanmanWorkstation service parameters too, so fixing the NAS is probably the best first step, if it can be done.


  3. In eventvwr, select View > Show Analytic and Debug logs (it will check that option). Then go down into the App and Services > Microsoft > Windows logs, and you will have 3 different Terminal Services folders with logs in them, as well as a Service Reporting API log folder. Enable all of the log options inside those folders that aren't already enabled (some will be, but others won't be by default) and then reproduce the issue. You should get some good logging there, hopefully.


  4. Microsoft will not support an installation of XP, Vista, Windows 7, etc. that has been modified in this way, and it does violate some of the contractual obligations that enterprise customers have with Microsoft in addition to the Windows license (violation of which by these products will vary by geography and political climate, of course). However, if you're in a business environment and you're running Windows, you will likely want and need support if anything does go wrong, and finding out at that point that Microsoft will refuse to help you with those installs is the absolute worst time to be there (I've seen this stance first hand, as well).

    If it's for personal use, it's probably OK and the only risk you take is having to modify your install or reinstall if it breaks, but in a business setting it's really a dumb move.


  5. You can petition all you'd like, but most software companies don't find it very wise to support a product no one is purchasing anymore. Also, Windows 7 is quite a worthy successor to Windows XP, and that's 2 major versions beyond it. XP was released in 2001, and we'll still get security update support for XP until April of 2014, almost 13 years after it was released. With how good Windows 7 is, I'd probably recommend looking to upgrade to Windows 7 before April 2014 (Windows 7 is supported until January of 2020).


  6. It's hard to say what's happening in the class driver under the Partition Manager, but it looks like while attempting to mount the RAID device the Intel storage driver caused a bugcheck:

    0x8E:

    // The bugcheck (crashing) stack:
    1: kd> kn
    *** Stack trace for last set context - .thread/.cxr resets it
    # ChildEBP RetAddr
    WARNING: Stack unwind information not available. Following frames may be wrong.
    00 b000f7c8 82c6e5be iaStor+0x2ff15
    01 b000f7e0 8bf86f2b nt!IofCallDriver+0x63
    02 b000f814 8bf92aba MpFilter+0xf2b
    03 b000f8a8 8bf926af MpFilter+0xcaba
    04 b000f8c4 8bf5519a MpFilter+0xc6af
    05 b000f930 8bf5a9ec fltmgr!FltpPerformPreMountCallbacks+0x1d0
    06 b000f998 8bf5ac5b fltmgr!FltpFsControlMountVolume+0x116
    07 b000f9c8 82c6e5be fltmgr!FltpFsControl+0x5b
    08 b000f9e0 82dd0daf nt!IofCallDriver+0x63
    09 b000fa44 82cdf57e nt!IopMountVolume+0x1d8
    0a b000fa7c 82e7cd19 nt!IopCheckVpbMounted+0x64
    0b b000fb60 82e5cc2e nt!IopParseDevice+0x7c9
    0c b000fbdc 82e6d040 nt!ObpLookupObjectName+0x4fa
    0d b000fc38 82e63b1e nt!ObOpenObjectByName+0x165
    0e b000fcb4 82e87396 nt!IopCreateFile+0x673
    0f b000fd00 82c7527a nt!NtCreateFile+0x34
    10 b000fd00 76e67094 nt!KiFastCallEntry+0x12a
    11 00bbe534 00000000 0x76e67094

    // The IRP for this thread should be in @edx...
    1: kd> r
    Last set context:
    eax=8890e800 ebx=00000000 ecx=0000000e edx=8890e790 esi=8890e790 edi=00000000
    eip=8be3af15 esp=b000f7b8 ebp=b000f7c8 iopl=0 nv up ei ng nz na pe nc
    cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
    iaStor+0x2ff15:
    8be3af15 8b4704 mov eax,dword ptr [edi+4] ds:0023:00000004=????????

    // ...and shows us in the Intel RST driver:
    1: kd> !irp 8890e790
    Irp is active with 1 stacks 1 is current (= 0x8890e800)
    No Mdl: System buffer=85dda0c0: Thread 85e4ca30: Irp stack trace.
    cmd flg cl Device File Completion-Context
    >[ e, 0] 0 0 864aab50 00000000 00000000-00000000
    \Driver\iaStor
    Args: 00000008 00000000 002d0c14 00000000

    // The originating IRP is also in iaStor - looks like whatever it was doing, it completed it:
    1: kd> !io 8890e790
    Irp is active with 1 stacks 1 is current (= 0x8890e800)
    No Mdl: System buffer=85dda0c0: Thread 85e4ca30: Irp stack trace.
    cmd flg cl Device File Completion-Context
    >[ e, 0] 0 0 864aab50 00000000 00000000-00000000
    \Driver\iaStor
    Args: 00000008 00000000 002d0c14 00000000

    Notification Event: b000f800

    [ e, 0] = IRP_MJ_DEVICE_CONTROL, IRP_MN_???

    IO Status: 0 : STATUS_SUCCESS

    File Object: 00000000

    Current Driver:
    No. MEMORY_RANGE CheckSum TimeStamp Flag Author Image Name Dist Version Path
    1 8be0b000 - 8bf0c000 00062058 4cd505bd Sat Nov 06 00:37:33 2010 ??? iaStor.sys \SystemRoot\system32\DRIVERS\iaStor.sys

    // Investigating the device object does point to iaStor, so this is probably accurate:
    1: kd> !devobj 864aab50
    Device object (864aab50) is for:
    IAAStorageDevice-1 \Driver\iaStor DriverObject 86565f10
    Current Irp 00000000 RefCount 1 Type 00000007 Flags 00005050
    Vpb 881de248 Dacl 90200d1c DevExt 00000000 DevObjExt 86569198 Dope 86561d58 DevNode 86597b70
    ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
    Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
    AttachedDevice (Upper) 880e43f0 \Driver\Disk
    Device queue is not busy.

    1: kd> !drvobj 86565f10
    Driver object (86565f10) is for:
    \Driver\iaStor
    Driver Extension List: (id , addr)

    Device Object list:
    864aab50 8654a028 86578028 8656c218

    // Looking back at the stack for what was being done on this thread, it looks like there was a drive mount happening:
    1: kd> .frame b
    0b b000fb60 82e5cc2e nt!IopParseDevice+0x7c9

    1: kd> dt CompleteName
    "\Device\Ide\IAAStorageDevice-1"

    // Version of the Intel RST driver:
    1: kd> lmvm iastor
    start end module name
    8be0b000 8bf0c000 iaStor (no symbols)
    Loaded symbol image file: iaStor.sys
    Image path: \SystemRoot\system32\DRIVERS\iaStor.sys
    Image name: iaStor.sys
    Timestamp: Sat Nov 06 00:37:33 2010 (4CD505BD)
    CheckSum: 00062058
    ImageSize: 00101000
    Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

    // Machine info:
    1: kd> !sysinfo machineid
    Machine ID Information [From Smbios 2.5, DMIVersion 37, Size=1616]
    BiosMajorRelease = 0
    BiosMinorRelease = 0
    FirmwareMajorRelease = 0
    FirmwareMinorRelease = 0
    BiosVendor = Intel Corp.
    BiosVersion = SOX5810J.86A.5529.2010.1214.2317
    BiosReleaseDate = 12/14/2010
    SystemManufacturer =
    SystemProductName =
    SystemVersion =
    BaseBoardManufacturer = Intel Corporation
    BaseBoardProduct = DX58SO
    BaseBoardVersion = AAE29331-501

    0x7E:

     // Thread running on CPU 0 at the time of this crash:
    1: kd> !thread 86fdfd48
    THREAD 86fdfd48 Cid 03e8.0dfc Teb: 7ff89000 Win32Thread: fde56ba8 RUNNING on processor 0
    Not impersonating
    DeviceMap 8c008ab8
    Owning Process 86b8e508 Image: svchost.exe
    Attached Process N/A Image: N/A
    Wait Start TickCount 106794 Ticks: 0
    Context Switch Count 488750 IdealProcessor: 0
    UserTime 00:00:42.681
    KernelTime 00:00:04.695
    Win32 Start Address 0x769712e5
    Stack Init a1ffdfd0 Current a1ffda48 Base a1ffe000 Limit a1ffb000 Call 0
    Priority 8 BasePriority 6 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
    ChildEBP RetAddr Args to Child
    8078add4 8f810560 862ca028 821b0380 854fa15c USBPORT!USBPORT_ProcessNeoStateChangeList+0x9 (FPO: [Non-Fpo]) (CONV: stdcall)
    8078ade8 820ca477 862ca028 00000000 8078ae94 USBPORT!USBPORT_DM_IoTimerDpc+0x20 (FPO: [Non-Fpo]) (CONV: stdcall)
    8078ae08 820c3019 821b0360 021b0318 1d9b665b nt!IopTimerDispatch+0x49 (CONV: stdcall)
    8078ae4c 820c2fbd 82173d20 8078af78 00000003 nt!KiProcessTimerDpcTable+0x50 (CONV: stdcall)
    8078af38 820c2e7a 82173d20 8078af78 00000000 nt!KiProcessExpiredTimerList+0x101 (CONV: stdcall)
    8078afac 820c100e 0001a12a a1ffdd34 00000000 nt!KiTimerExpiration+0x25c (CONV: stdcall)
    8078aff4 820c07dc a1ffdce4 00000000 00000000 nt!KiRetireDpcList+0xcb (CONV: fastcall)
    8078aff8 a1ffdce4 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c (FPO: [Uses EBP] [0,0,1])
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    820c07dc 00000000 0000001a 00d6850f bb830000 0xa1ffdce4

    // The only other active thread at the time, running on CPU 6:
    1: kd> !thread 85551d48
    THREAD 85551d48 Cid 0004.011c Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 6
    Not impersonating
    DeviceMap 8c008ab8
    Owning Process 84afe820 Image: System
    Attached Process N/A Image: N/A
    Wait Start TickCount 105903 Ticks: 891 (0:00:00:13.899)
    Context Switch Count 111385 IdealProcessor: 6
    UserTime 00:00:00.000
    KernelTime 00:05:04.311
    Win32 Start Address iaStor (0x8b10e424)
    Stack Init 8e007fd0 Current 8e007ad0 Base 8e008000 Limit 8e005000 Call 0
    Priority 16 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
    ChildEBP RetAddr Args to Child
    8e007d24 8b10e273 00000000 85551d48 00000000 hal!KfReleaseSpinLock+0x4 (FPO: [0,0,0])
    WARNING: Stack unwind information not available. Following frames may be wrong.
    8e007d44 8b10e432 8552eb38 8e007d90 82252056 iaStor+0x1c273
    8e007d50 82252056 8552eb38 a9190b2c 00000000 iaStor+0x1c432
    8e007d90 820fa1a9 8b10e424 8552eb38 00000000 nt!PspSystemThreadStartup+0x9e (CONV: stdcall)
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

    The USBSTOR stack running on CPU 0 is calling _ProcessNeoStateChangeList, which parses USB endpoints to find attached devices and as such requires elevation of IRQL to dispatch mode to parse for those potential endpoints. The iaStor stack of the loading of the iaStor driver (doing something, but not obvious what without symbols) has a dispatch IRQL and is in the process of releasing a SpinLock at the time of the bugcheck. I don't believe that the USB stack is in any way related, because in it's current state, it is waiting for this iaStor thread to finish - in essence, it is doing nothing but waiting.

    Ultimately, both of these dumps seem to point to either the Intel driver, or whatever it's mounting. It looks like this is an Intel DX58SO board, and the latest RST driver for that board is the November 2010 release, according to Intel, which it looks like the install is already using. Short of a BIOS update to the May 2012 release, I'm not sure what else you could try short of removing the drives and trying with known good ones. It does look like either a driver or, more likely, drive or array problem.


  7. I'd bet this has something to do with it - from the KB article, in the fine print for Windows Server 2008 R2:

    This update is only applicable for Windows Server 2008 R2 systems when the Ink Support component of the optional Ink and Handwriting Services feature has been installed and enabled. See the update FAQ for details.

    Unless you have people using 2008 R2 servers with pen input (or touch) capabilities, you don't really need the Ink and Handwriting Services feature enabled at all, for what it's worth.


  8. I'm not sure what misinformation you speak of in that technet blog post, as it is accurate - however, those KBs are quite useful as you have noted. Ultimately a GDR (general distribution release) almost always contains security fixes only - rarely (if deemed a large enough issue that everyone running that OS the world over should get a fix) a GDR will contain a non-security-related bugfix (or fixes, I suppose). Most non-security (bugfix/functionality change) updates release in the LDR code branch (Limited Distribution Release, previously known as a QFE prior to Vista - Quick Fix Engineering). An LDR or QFE update will contain all of the GDR (security-related) update code to that point, but also contain the non-security bugfix or functionality changes as well.


  9. You could also just use DISM - assuming you have all the .MSU files, you simply use DISM to slip all the updates into the offline WIM file. Doesn't require any tools that don't already ship with Windows.

    Apply Updates to an Image Using DISM

    You can do the same thing with drivers, although you may need to extract their installation packages before you can point DISM at them:

    Add and Remove Drivers Offline


  10. Well, Windows 8 feels faster because it does things differently (more efficiently), especially during boot and shutdown. It has little to do with the usual things in this case, but yes, registry and profile bloat will have some effect long-term.


  11. One important question you'll want to answer before you go too far - what do you intend on using this WIM for? If it will be used for anything commercial/enterprise and/or non-personal, you want to avoid things like vLite/RT7Lite and other tools that actually hack away at Windows files and catalogs to remove components. Most of them violate the Windows EULA in some way, so if you plan on putting these into a place where support from Microsoft or compliance with licenses is required (or desired), be wary of 3rd party tools that "remove" components above and beyond what DISM does. Just FYI.


  12. I know you can bypass this if you use MDT to deploy Windows 8 (it allows you to skip certain checks, including CPU), but I don't have a machine to test that on that fails the CPU check.

    It's very interesting, though - either the vCPU or vBIOS isn't telling the Windows 8 installer something it supports properly, or there's some other undocumented check. I've got a Core2Quad 9550 that runs it fine in Hyper-V, and an i5 2467M that also run it ok under Hyper-V on both 2008 R2 and Windows Server 2012 CP. Not sure what it is about that vCPU or the vBIOS (or both) in VirtualBox, but I have heard complaints that running Win8 RP under VirtualBox is painfully slow on higher-end hardware underneath, so YMMV with VirtualBox in any case.

    I guess it'd be interesting if a VM running inside VirtualBox on that system really was reporting if NX was enabled inside the VM via something like CoreInfo. That error code usually indicates the answer is no for some reason.

×
×
  • Create New...