win 7 64 bit "repair" and windows update

On Jan 3, 4:59*am, miso <m...@sushi.com> wrote:
> I have a program that crashes. I think the software is junk. However,
> someone with a bit more invested in the code thinks I have a "broken" DLL..
>
> I vaguely remember doing the MS "repair" using the installation disk. My
> question is does Windows update notice this repair and then select the
> proper updates? I assume the service pack should be installed after the
> repair.

Unfortunately I'm not qualified to address this question that you
actually asked - that is, whether the "repair" options on your disk
interfere with Windows Update replacements of original DLLs with this
not being detected by Windows Update subsequently. But that would be
a grave and common problem if it existed, surely?

I have a vague recollection that Windows Update may have a history of
past updates - I was just looking at it in fact - that can be erased,
causing Windows Update to re-consider and re-test whether all existing
updates are required on your PC or are already there. But I'm not
sure about this.

Some authorities prefer simply reinstalling Windows from scratch when
something goes wrong. I found one such when looking for references to
a problem that turned out to be a hugely faulty non-ECC memory module,
not detected by BIOS test (omitting EFI diagnostics because I'd
misplaced the SD card copy of the EFI software) but detected by
Memtest86+ on the free-download bootable SystemRescueCD. I thought
that responding to the blue-screen at boot that /did/ indicate a
memory problem, by reinstalling Windows from scratch, was premature.
But if you can do that - or can restore a previous working system
image - it does cut out much fiddling around.

I think in your case you are not quite on firm ground if the PC isn't
Microsoft-certified Windows 7 hardware or other third-party assured.
You're right, all software has bugs. But so does almost all
electronics, including the CPU itself.

On 1/4/2012 3:56 AM, Jeff Layman wrote:
> On 04/01/2012 08:35, miso wrote:
>> On 1/3/2012 11:51 PM, Jeff Layman wrote:
>
> (snip)
>
>>> Just in case there is a corrupt win7 * .dll file, have you considred
>>> running sfc /scannow?
>>> (http://support.microsoft.com/kb/929833)
>>>
>> Now we're talking. I forgot about that command. It turns out win 7
>> security has a special trick so you can get administrator permission on
>> the command prompt. You put CMD in the search line, but hit
>> cntl+shift+enter to get administrator permission for the command prompt.
>> It seems being administrator isn't enough, or I have permissions set
>> strangely.
>
> Why not just right-click on cmd.exe and select "Run as administrator"?
>
>> In any event, that was a good idea. It found no problems. But does that
>> really prove all my dlls are sound? What does that command use as a
>> reference? Do it check a byte count or something like that?
>
> Did you check the log that sfc makes? See Option Three here:
> http://www.sevenforums.com/tutorials...e-checker.html
>
>
> According to the wiki
> https://secure.wikimedia.org/wikiped...m_File_Checker
> "System File Checker is integrated with Windows Resource Protection,
> which protects registry keys and folders as well as critical system
> files....Windows File Protection works by registering for notification
> of file changes in Winlogon. If any changes are detected to a protected
> system file, the modified file is restored from a cached copy located in
> a compressed folder at %WinDir%\System32\dllcache. Windows Resource
> Protection works by setting discretionary access control lists (DACLs)
> and access control lists (ACLs) defined for protected resources.
> Permission for full access to modify WRP-protected resources is
> restricted to the processes using the Windows Modules Installer service
> (TrustedInstaller.exe). Administrators no longer have full rights to
> system files."
>

If you right click on the command and do run as administrator, how do
you feed it the parameters? In any event, control+shift is trivial once
you know about it's existence. [Much like the secret mode in the bios on
my old PC to get into the "advanced" settings. It was so secret it
wasn't documented.]

On 1/4/2012 8:35 AM, Robert Carnegie wrote:
> On Jan 3, 4:59 am, miso<m...@sushi.com> wrote:
>> I have a program that crashes. I think the software is junk. However,
>> someone with a bit more invested in the code thinks I have a "broken" DLL.
>>
>> I vaguely remember doing the MS "repair" using the installation disk. My
>> question is does Windows update notice this repair and then select the
>> proper updates? I assume the service pack should be installed after the
>> repair.
>
> Unfortunately I'm not qualified to address this question that you
> actually asked - that is, whether the "repair" options on your disk
> interfere with Windows Update replacements of original DLLs with this
> not being detected by Windows Update subsequently. But that would be
> a grave and common problem if it existed, surely?
>
> I have a vague recollection that Windows Update may have a history of
> past updates - I was just looking at it in fact - that can be erased,
> causing Windows Update to re-consider and re-test whether all existing
> updates are required on your PC or are already there. But I'm not
> sure about this.
>
> Some authorities prefer simply reinstalling Windows from scratch when
> something goes wrong. I found one such when looking for references to
> a problem that turned out to be a hugely faulty non-ECC memory module,
> not detected by BIOS test (omitting EFI diagnostics because I'd
> misplaced the SD card copy of the EFI software) but detected by
> Memtest86+ on the free-download bootable SystemRescueCD. I thought
> that responding to the blue-screen at boot that /did/ indicate a
> memory problem, by reinstalling Windows from scratch, was premature.
> But if you can do that - or can restore a previous working system
> image - it does cut out much fiddling around.
>
> I think in your case you are not quite on firm ground if the PC isn't
> Microsoft-certified Windows 7 hardware or other third-party assured.
> You're right, all software has bugs. But so does almost all
> electronics, including the CPU itself.

The mem test is on most linux distribution disks as well. I can run that
and see what happens.

Regarding my hardware being certified, all I can say is anything I ever
built is of better quality than what you buy from HP, Dell, etc.
Especially the power supplies. I don't overclock.

If it passes the mem test, I will see if the programmer will compile a
debug version. I really don't want to reinstall windows, especially when
I only have one program that has this crash. Especially a crash that is
trapped, which is different than BSOD. The OS knows this program is
trying to go outside it's protected memory, trapps it, and keeps the
rest of the system working just fine. I have more faith in win 7 than a
one person programming company.

> I'm not sure what the difference is. With your method, you get a box
> entitled "Administrator:C:\Windows\system32\cmd.exe". With my method,
> you get a box entitled "Administrator : Command Prompt". With both, the
> cursor is waiting at C:\Windows\system32.
>

I was thinking you meant to right click on scf, not CMD. In any event,
it is zero effort to do the control-shift. I like keyboard shortcuts.