waqqas31

Well, I found a way to fix the problem AFTER-the-fact (not the preventative solution I am seeking above). But for the benefit of anyone experiencing the same symptoms, here is the solution: 1. Set Windows to use Normal (96 dpi) fonts the normal way (search for "font size"). Restart. 2. Make a "Fix_DPI.reg" text file with the following contents and then run it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontDPI] "LogPixels"=dword:00000060 [-HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\FontDPI] [HKEY_CURRENT_USER\Control Panel\Desktop] "LogPixels"=dword:00000060 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts] "MS Sans Serif 8,10,12,14,18,24"="SSERIFE.FON" "MS Serif 8,10,12,14,18,24"="SERIFE.FON" "Courier 10,12,15"="COURE.FON" 3. Restart and you're done. For a full explanation, see these links: http://www.sevenforums.com/tutorials/443-dpi-display-size-settings-change.html http://answerleaks.com/question/server/88045/deploying-windows-7-using-wds-some-applications-seem-to-be-stuck-at-125-dpi-settings http://blogs.msdn.com/b/developingfordynamicsgp/archive/2009/11/25/windows-7-bitmap-fonts-and-microsoft-dynamics-gp.aspx?CommentPosted=true#commentmessage

Here is the issue I am having, and it only happens on my notebook (Dell Studio XPS 1640 with ATI Radeon HD 4670 and a 1080p screen.) Whenever I install Windows 7, during the "Completing Installation" phase, it detects the video card and successfully installs the drivers (like it should). But then Windows automatically switches to 120 dpi font-size ("Large Fonts") upon the first post-install boot-up. Now, this shouldn't be an issue if it could properly be reversed. After logging in, etc, and switching back to 96 dpi font-size ("Normal" font size) and restarting, etc, not all elements of my desktop revert to 96 dpi. In particular, text elements in (some) dialog boxes still appear like they would in "Large Fonts" mode, but the graphical elements would be sized for "Normal" fonts! So, there are incidents of overlapping text and graphics, text spilling outside the border of the dialog-box, etc. I even googled for and found registry keys to modify to get these elements back to their natural state, but nothing worked. I even tried installing while plugged in to an external display (my 1080p TV) and the same thing happened. What DID work was plugging in an external display with lower resolution (1366x768 and 1280x1024 both work) while installing and Windows will NOT automatically enable 120 dpi fonts. Now, I install Windows 7 on computers at work on almost a daily basis and we use 1920x1080 and 1920x1200 screens 90% of the time and this has never happened. My understanding is that Windows detects a notebook or a mobility graphics chipset is being used and figures that 1080p will strain your eyes on a (probably) small LCD screen, so it does you a favor by automatically enlarging the font-size. Windows' heart may be in the right place, but this results in a corruption of UI fonts that cannot be corrected. And we are actually approaching a time where it will be difficult to find low-res screens to pull off the trick I mentioned earlier, so I hope I won't be condemned since I *only* purchase laptops with 1080p or higher-res screens. Any input on how to fix this would be greatly appreciated, or (possibly) alternatively, how I can force Windows to install in Standard VGA mode or bypass installing any video driver whatsoever. Thanks!!

Before you ask, there's a small bug in v4.8.0 that will be fixed in upcoming release. Here's an easy workaround for running systems: copy and paste these lines in Notepad. [Version] Signature="$Windows NT$" [DefaultInstall] AddReg =REGEntries.AddReg [REGEntries.AddReg] HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\62A79A60FA1136F438E2F4263C7A1D63","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\7A0DCDED98788304DB93CC7B4D95E24D","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\815DE197FE1BE664CB88CB6D3CA9C629","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\FD01C6A9B00EFA749A5683F6D47045BD","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\FD01C6A9B00EFA749A5683F6D47045BD","00000000000000000000000000000000", ,"%24%" and save with .inf extension (EG fix.inf). Then run it, this should fix the MU issue Didn't work, btw Same updates fail to install.

Yes, that's the one. Before you ask, there's a small bug in v4.8.0 that will be fixed in upcoming release. Here's an easy workaround for running systems: copy and paste these lines in Notepad. [Version] Signature="$Windows NT$" [DefaultInstall] AddReg =REGEntries.AddReg [REGEntries.AddReg] HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\62A79A60FA1136F438E2F4263C7A1D63","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\7A0DCDED98788304DB93CC7B4D95E24D","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\815DE197FE1BE664CB88CB6D3CA9C629","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\FD01C6A9B00EFA749A5683F6D47045BD","DC3BF90CC0D3D2F398A9A6D1762F70F3", ,"%24%" HKLM,"Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\FD01C6A9B00EFA749A5683F6D47045BD","00000000000000000000000000000000", ,"%24%" and save with .inf extension (EG fix.inf). Then run it, this should fix the MU issue Was this bug also in 4.6.0? That's the only other version I tried and I experienced the same issue. Thanks in advance!

The dot NET portions have been giving me headaches with Microsoft Update and I was *hoping* to ask the author about them.

Try to repeat method 1 but use index 2 instead index 1. It should work like a charm! bye bye @n1cepeg: Thanks for the tip. Worked first time!

Did you use a different method to create it?

Well, folks, I seem to have found a solution. It seems like the new install.wim file might have been too big to handle (quickly, at least). I split the install.wim file into smaller install.swm files using ImageX and the response time was back to what I experienced on the MSDN discs. To summarize: ImageX /split install.wim install.swm 1024 (This will split the WIM file into 1GB chunks) Delete install.wim from the sources folder and replace with these install*.swm files. I tried first with files named splitinstall.swm but it did not work!

Yes, the other disks work fine. I'm going to clarify what I did, since I'm not sure if you meant to ask "Why not extract...." or "Why did you extract...." I took the MSDN Vista x86 disk, and copied the install.wim file to my hard drive. I did the same with the x64 disk. Now, the x86 install.wim had 7 images, including two "N" versions that I don't need. So, I created a new install.wim file and exported images to it until I had collected all the ones I wanted. This is the command I used: imagex /export x86\install.wim 1 install.wim "Windows Vista Business x86 SP2" imagex /export x86\install.wim 2 install.wim "Windows Vista Home Basic x86 SP2" ... imagex /export x64\install.wim 3 install.wim "Windows Vista Home Premium x64 SP2" imagex /export x64\install.wim 4 install.wim "Windows Vista Ultimate x64 SP2" My install.wim had a total of 9 images in it (5 x86 images, 4 x64 images). I then edited an ISO of the MSDN x86 disk in UltraISO, by replacing its install.wim with my new 9-in-1 install.wim that I just created. Everything else in the ISO remained unchanged. Now, are you suggesting that instead of exporting all 9 images to 1 newly-created install.wim file, I should export them to 2 new separate install.wim files and then combine the two? If so, how would that explain the issue I've been experiencing? Thanks! Waqqas

Hi everyone, I used this tutorial: http://www.windowsvalley.com/create-windows-7-aio-all-in-one-dvd-or-merge-all-editions-of-windows-7-in-single-dvd/ Though what I did differently is that I extracted only the install.wim files from the MSDN Vista disks, exported the images as required from the x64 install.wim to the x86 install.wim, then used UltraISO to save the x86 ISO with an updated install.wim file. I used this method with both Vista SP2 and Windows Server 2008 SP2, and both resulting discs work just fine, but the initial steps in Windows setup have a significant amount of lag compared with the original MSDN discs and other peoples' AIO creations. Any idea on how to fix the sluggishness? It's particularly sluggish from the license key screen until it finally starts installing. I tested the install speed on both a virtual machine and a Dell Latitude D630 notebook. TIA, Waqqas

Thanks for the feedback! I will explore those options. Although, I could have sworn that those downloads I was alluding to were smaller AND installed in normal time. Adding the OnePiece to my disc causes a considerable delay at the 23-minute mark.

Browsing P2P sites has shown me ISO's smaller than 500MB, completely up-to-date (January 2011). I've also found ISO's around 600MB that were up-to-date yet not stripped down in any way. When I tried updating my own disc using nlite and OnePiece's update pack, my ISO was much larger, closer to 800MB. Can anyone shed some light on how to make the ISO's smaller? Thanks in advance, Waqqas

Thanks! That helped quite a bit

Hello Everyone, What I'm trying to achieve is installing different sets of programs, depending on what the system is meant for. So, I was thinking that different config files can be set up for regular business PC's, versus multimedia workstations or development workstations. The problem is that WPI always launches with config.js. Even if I go to config and load a different config.js-type file, shutting down WPI will reset it back to the defaults. Are there command-line arguments to allow me to launch WPI with specific config files? The documentation doesn't say very much at all on how to work with multiple config files, even though this is obviously a supported feature. All help and guidance is appreciated!

This method is not working for me. Mine fails immediately, even though when I run the same batch file from the command prompt it works just fine. Any idea what I could be doing wrong? Can you share your entire batch file so I can compare it with mine? I tried slimming my batch down to this: @ECHO OFF start /wait setup.exe /adminfile silent_install.msp And it still didn't work, albeit with a different error message (something like install programs from the Control panel, etc).