Page 1 of 2 12 LastLast
Results 1 to 10 of 19
  1. #1
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    5,986

    Default Windows 10 Feature Update 2004 comments

    Bob,

    I just wanted to comment on your thread above (http://forums.dc3.com/showthread.php...2119#post82119).

    I installed the latest Windows version 2004 update a couple weeks ago. Yes, it installs the "new" broken JET .dlls, both labeled version 4.0.9801.24. But before installing the update, I had changed the Date Modified of each good working file (msjet40.dll and msrd3x40.dll) to the date of my planned update install. That didn't prevent the good .dlls from being overwritten with the newer bad ones.

    So I replaced them once again with the good old files, only this time I changed their Product version/File version numberss to the current version number ...24. Now I'm waiting for another KB update to see whether a new update will replace those good files with the bad ones again. There has to be some cue that the update takes in order to know if it has to install new files - perhaps the version number is that cue.

    In the meantime, other than this wrinkle, Windows 10 (2004) is working well for me.
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XMEv
    H-alpha, BVRI, RGB & Clear filters
    FOV ~15’ x 10’



  2. #2
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    33,158

    Default

    Thanks for that info Dick. Did you see this update from me yesterday?
    -- Bob

  3. #3
    Join Date
    Nov 2015
    Location
    Christchurch, Dorset, United Kingdom
    Posts
    347

    Default Testing for .dll persistence

    Quote Originally Posted by Dick Berg View Post
    Bob,

    I just wanted to comment on your thread above (http://forums.dc3.com/showthread.php...2119#post82119).

    I installed the latest Windows version 2004 update a couple weeks ago. Yes, it installs the "new" broken JET .dlls, both labeled version 4.0.9801.24. But before installing the update, I had changed the Date Modified of each good working file (msjet40.dll and msrd3x40.dll) to the date of my planned update install. That didn't prevent the good .dlls from being overwritten with the newer bad ones.

    So I replaced them once again with the good old files, only this time I changed their Product version/File version numberss to the current version number ...24. Now I'm waiting for another KB update to see whether a new update will replace those good files with the bad ones again. There has to be some cue that the update takes in order to know if it has to install new files - perhaps the version number is that cue.

    In the meantime, other than this wrinkle, Windows 10 (2004) is working well for me.[/QUOTEQUOTE=Dick Berg;83653]Bob,

    I just wanted to comment on your thread above (http://forums.dc3.com/showthread.php...2119#post82119).

    I installed the latest Windows version 2004 update a couple weeks ago. Yes, it installs the "new" broken JET .dlls, both labeled version 4.0.9801.24. But before installing the update, I had changed the Date Modified of each good working file (msjet40.dll and msrd3x40.dll) to the date of my planned update install. That didn't prevent the good .dlls from being overwritten with the newer bad ones.

    So I replaced them once again with the good old files, only this time I changed their Product version/File version numberss to the current version number ...24. Now I'm waiting for another KB update to see whether a new update will replace those good files with the bad ones again. There has to be some cue that the update takes in order to know if it has to install new files - perhaps the version number is that cue.

    In the meantime, other than this wrinkle, Windows 10 (2004) is working well for me.

    Hello Dick.

    You don't have to wait until the next monthly update to test whether your changes to the DLL's identifiers are ignored, open an elevated Command Prompt window (type CMD in the lower search box and from the "Best Match" list right-mouse-click "Command Prompt" and select "Run as Administrator" from the context menu).

    In the elevated Command Prompt window type the string "sfc /scannow" (without quotes) and this will run a Windows tool that will compare the core Windows DLL's that you see (and modify for example) in the Windows SysWOW64 folder, with a master backup DLL cache that is hidden away on the hard drive and will replace any that it thinks are corrupted, modified without a valid developer certificate or do not match the version specified by the last quality update.

    Running sfc /scannow will replicate what happens when a quality update is installed so you can make many attempts to try fooling Windows to ignore those JET .dll files and then sfc /scannow will revert them back to the default (signed) versions from the backup cache. Trying to fool Windows is tough nut to crack as the files are identified by hidden as well as visible markers and certificates to prevent malicious hacking. Windows 10 is tied up pretty tight to prevent us users from making unauthorised modifications, still, provides plenty of 'play' time on a rainy afternoon!

    Before Windows 10 it was easy to just slip in an Application Manifest file written in XML stating .dll dependencies (sample code below) together with copies of the good .dll's to your applications root folder and at run time of your app i.e, Scheduler.exe, Windows would read the Application Manifest and log that you wanted your versions of the specified .dll's to take precedence over the copies found in the SysWOW folder and load your specified dll's into memory but I spent a couple of weeks trying to make this work and it seems that in Windows 10 you can only do this with a dedicated side-by-side assembly and these need to be signed with a Microsoft developer certificate which are not free to obtain.

    Pre Windows 10 if you did a wild card search of the C:\ drive for *.manifest you would have found hundreds of Application Manifest files that were used to state .dll dependencies and avoid this so called "DLL Hell" but if you do the same search with Windows 10 you will mostly find just Microsoft still using them and those are for dedicated side-by-side assemblies containing the required versions of the .dll's and are signed with developer certificates and secure SHA hashes.

    I tried many variations of the application manifest and copies of the older .dll's in the Scheduler folder but none worked and it might be that 'scheduler.exe' does not call the JET database engine directly and so the Application Manifest is ignored or it might be that in Windows 10 the older Windows core .dll's have to be digitally signed with a developer certificate and stored in the Windows SxS folder, either way, with very little up-to-date information available regarding Application Manifest files specifically for Windows 10 on the Windows developer web pages I gave up after trying various scenarios for a couple of weeks.

    Microsoft haven't exactly made it easy for developers re the future of the JET Database Engine as they announced a few years ago that JET, which has been around since the late 1980's was to be deprecated in 2018 and then changed their minds and released new versions of Access in 2019 that depend on JET so it seems that JET will be around for quite a while as Bob posted recently.

    If Bob were to begin building Scheduler today I guess he would use SQL lite rather than JET since Microsoft have said that SQL is their preferred database going forward and MS could change their minds again in a few months and say sorry but we are going to deprecate JET in the next Windows build.

    Makes me glad I chose medical engineering as a career and not software development....would drive me mad trying to second guess MS all the time..

    William.

    Code:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity type="win32" name="ACP.Expert Scheduler" version="8.3.2.0" processorArchitecture="x86"/>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity 
          type="win32" 
          name="msjet40.dll" 
          version="4.0.9801.20" 
          processorArchitecture="x86"/>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity 
          type="win32" 
          name="msrd3x40.dll" 
          version="4.0.9801.19" 
          processorArchitecture="x86"/>
        </dependentAssembly>
      </dependency>
    </assembly>
    

  4. #4
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    5,986

    Default

    William,

    Thank you for this detailed explanation and instructional guide. I will try your suggestion to test the update process, and I’m betting it will show me that applying updates has nothing to do with the .dll version information. It couldn’t possibly be so simple!

    You surely have a second career waiting for you when you get tired of your first career.

    Thanks again.
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XMEv
    H-alpha, BVRI, RGB & Clear filters
    FOV ~15’ x 10’



  5. #5
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    5,986

    Default

    (Bob, Yes, I did see your note about the conversation with the Microsoft Insider.)

    Hi William,

    Well, very interesting, and surprising! I did the sfc /scannow experiment:

    CMD.jpg

    So changing the version or date properties clearly changed the hash, which sfc picked up. In the CBS.log file (attached if you're interested) you can search on "do not match" and see two sets of eight non-matches, at 12:38:46 and 12:38:51, for just the two files msjet40.dll and msrd3x40.dll. No other mismatches were detected anywhere else.

    For the final test of the successful non-repair, the only time you might root for a repair to fail, I reloaded the schedule browser several times, as Bob had indicated earlier, and saw no growth in the size of either .dll file. So "sfc" did indeed leave the good (old) .dlls in place.

    I don't know if this means anything for some kind of permanent solution, but it's an interesting result. Thanks for sharing your know-how.
    Attached Files Attached Files
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XMEv
    H-alpha, BVRI, RGB & Clear filters
    FOV ~15’ x 10’



  6. #6
    Join Date
    Nov 2015
    Location
    Christchurch, Dorset, United Kingdom
    Posts
    347

    Default Windows image faulty...

    Quote Originally Posted by Dick Berg View Post

    So changing the version or date properties clearly changed the hash, which sfc picked up. In the CBS.log file (attached if you're interested) you can search on "do not match" and see two sets of eight non-matches, at 12:38:46 and 12:38:51, for just the two files msjet40.dll and msrd3x40.dll. No other mismatches were detected anywhere else.


    I don't know if this means anything~~.
    Hello Dick.

    It looks as though your Windows Image, the one that Windows uses for repairs and updates is corrupted, the CBS log states that it could not replace your modified .dll's in the SysWOW64 folder because it thinks the ones in the backup SxS store are corrupted too.

    This happens when updates go awry such as when a roll-back does not complete successfully or the Windows Image inventory manifest that lists all the valid file versions becomes corrupted.
    We see this quite a lot with our student's laptops after they have been in use for a year or two and quite frequently after a major build update to an existing system such as migrating from 1903 to 1909 to 2004 etc.

    If this is on your main observatory computer I would recommend you carry out the following repair to restore the Windows image just in case underlying problems manifest themselves when running your application programs.

    This is a non-destructive method of repairing Windows without having to reload Windows or your apps from scratch and everything *should* work just as before after the fix but it is a good idea to have a backup just in case.
    Our faculty I.T. dept recommend this following method in preference to the built-in re-install Windows option of Windows 10 because unfortunately that method just restores Windows from the current Windows image and update repository on-disk and if that is damaged, as your's appears to be then you just rebuild Windows with the same corrupted files.

    1. Using Edge browser on the system you want to repair type "Windows 10 ISO download" in the search bar and from the result list navigate to your region locale official Microsoft site and download the Microsoft Media Creator tool.

    2. Run the Media Creator tool and select the option to create a Windows 10 ISO file for use with another computer, change the default location for the creation of a Windows 10 ISO file to create the file on your user desktop and not the usual download folder, you need this ISO file on the desktop.
    The tool should automatically detect that you have build 2004 installed (for example) and that is the ISO file you will create but it may offer you a choice of older builds, it is important to select the same build version that you currently have installed, you can't use this repair method to repair another build version than the one you currently have.

    3. The download is large, ~4.7Gb, after download is complete you will have a Windows 10 ISO file on your desktop with the name "windows.iso"

    4. Right-mouse-click the windows.iso file on the desktop and select "Mount" from the context menu to create a temporary virtual DVD drive, an explorer window will open, make a note of the drive letter that has been assigned to the virtual drive, you need this drive letter for the next step.

    5. Close all unnecessary running programs and then open an elevated Command Prompt window as described in the earlier post.

    6. Open notepad and type or copy-paste the following text string into a blank page:


    DISM /Online /Cleanup-Image /RestoreHealth /Source:X:\sources\install.wim /LimitAccess



    edit the text string and replace the drive letter "X" in the term "/Source:X:" with the actual drive letter for the virtual DVD drive that you noted above, if you manually type the text string observe the spaces where appropriate.

    7. Copy the modified text string in notepad and paste it into the Command Prompt Window then hit enter.

    The DISM tool will now rebuild the computers Windows image file from the pristine copy of Windows that you just downloaded. The term at the end of the text string "\LimitAccess" forbids DISM from using the files in the computers existing update folder and it will only rebuild the Windows image from the latest file versions on the ISO so bypassing any problems with your computers update repository.

    8. After DISM has reported completion, which can take upon to an hour, run the sfc /scannow command again in the Command Prompt window to replace the live Windows OS files currently in use with those in the new Windows image you just created.

    9. Finally, and before rebooting, right-mouse-click the windows.iso file on the desktop and click "unmount' in the context menu to clear the virtual DVD drive and "eject" (virtually) the iso file.

    10. Reboot the computer, you should then run a check for updates but normally the .iso you downloaded would have all the latest updates already included and most likely Windows will find no updates are needed.

    That should be it Dick, after running DISM.exe and sfc /scannow using local .iso support you will have rebuilt a clean Windows environment, including the recovery image.

    You can delete the .iso file, there is no need to keep it, you can also recover some disk space if you type "disk cleanup" in the desktop lower toolbar and run the disk cleanup tool, use the options tab in the tool and clear the old backup recovery points and updates store, these are no longer relevant after running DISM with .iso support.

    William.
    Last edited by William Bristow; Aug 2, 2020 at 10:13.

  7. #7
    Join Date
    Nov 2005
    Location
    Virgil, NY
    Posts
    5,986

    Default

    William,

    Interesting observations. What puzzles me is that I used the Media Creator tool to download the latest Windows 10 (2004) image when I updated the home computer July 2nd and the observatory computer on July 14th. (Build 19041.388). I ran this as "update this PC" and not to create an ISO file. So it's hard for me to understand how this Windows Image could be corrupted in just a few weeks, considering your comment about years.

    I have another question. If there are no other "failures" shown in CBS log, is it certain that there are no other issues with any other components of the Windows Image?

    Before going on to do another MediaCreator ISO download, I tried another "experiment." Since I took permissions to modify the two relevant JET files in SysWOW64, I relocated the msjet40.dll to another folder (removed it from SysWOW64) and then re-ran sfc /scannow. I left msrd3x40.dll in place. I wanted to see what happens in this situation. If the missing file is replaced, the Windows Image is most likely not corrupted. If it's not replaced, then there is something wrong indeed with the Windows Image.

    sfc /scannow only took about three minutes to run. I got the same messages from the command prompt window about "corrupt files." msjet40.dll was NOT written into the SysWOW64 folder! And the CBS.log file posted the same errors about a hash mismatch. I also ran sfc /scannow on the observatory computer. I got the same results. On both computers, the JET files were not replaced.

    I'm moving on to your repair described above. I will post again after getting a new ISO image to rebuild the Windows Image, and running sfc /scannow once again.

    I do have a philosophical question about all this. It's probably a stupid question - I do believe in having "good" software on board. But if only these two files are corrupted in the Windows Image, and I like the result that an update does not replace the Jet files, why would I want to repair the Windows Image file? At least for now? If I do, then it's only to have to go through the tedious tasks of either compressing the Scheduler database or retaking permissions and replacing the updated msjet... and msrd3x... files with the good old ones.

    The real solution is of course in the hands of Bob and Microsoft.
    Dick
    www.VirgilObservatory.us
    Pier-mounted Meade 12-inch SCT "classic"
    Optec TCF-S focuser
    SBIG CFW-8A and ST7-XMEv
    H-alpha, BVRI, RGB & Clear filters
    FOV ~15’ x 10’



  8. #8
    Join Date
    Jun 2015
    Posts
    867

    Default

    Hi, I guess this is where we respond to the JetComp issue. My db is now up to 1.8 GB and would like to compact it but JetComp does not run... carefully followed your instructions.

    Run with or without admin privileges I cannot type a new name in and have it run and if I use the existing empty database it also fails... "Error compacting database".

    Is it possible to read the file into MS Access and compress it that way?

    I have a license through the University but have not bothered to install since Access is generally a disaster.

    System is still running but looks like I am on the edge.

  9. #9
    Join Date
    Oct 2005
    Location
    Mesa, AZ
    Posts
    33,158

    Default

    It is funky. Definitely do not touch the Empty Scheduler Database. Here's how I do it:

    1. Exit from ACP and Scheduler. They must not be running.
    2. Open Jetcomp
    3. Select SchedulerData.mdb in the From (source) by using the [...] browse button
    4. Copy the entire path from the source box to the destination box (C:\Program Files (x86)\ACP Scheduler\SchedulerData.mdb)
    5. Add 2 to the destination name to make it unique (C:\Program Files (x86)\ACP Scheduler\SchedulerData2.mdb)
    6. Click Compact. It should run.
    7. Throw away SchedulerData.mdb
    8. Rename SchedulerData2.mdb to SchedulerData.mdb
    -- Bob

  10. #10
    Join Date
    Jun 2015
    Posts
    867

    Default

    Quote Originally Posted by Bob Denny View Post
    It is funky. Definitely do not touch the Empty Scheduler Database. Here's how I do it:

    1. Exit from ACP and Scheduler. They must not be running.
    2. Open Jetcomp
    3. Select SchedulerData.mdb in the From (source) by using the [...] browse button
    4. Copy the entire path from the source box to the destination box (C:\Program Files (x86)\ACP Scheduler\SchedulerData.mdb)
    5. Add 2 to the destination name to make it unique (C:\Program Files (x86)\ACP Scheduler\SchedulerData2.mdb)
    6. Click Compact. It should run.
    7. Throw away SchedulerData.mdb
    8. Rename SchedulerData2.mdb to SchedulerData.mdb
    Well does not work for me. Even with full path copied. It will not allow me to define the target. Tried to use a copy of a file in the directory and it still fails. There is a lot on the web about this program failing... will look into Access.

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Windows 10 2004 coming soon. Any experiences?
    By Colin Haig in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 1
    Last Post: Jun 4, 2020, 23:58
  2. GOOD NEWS: Green Light for Windows Feature Update 1909 and ACP
    By Bob Denny in forum Windows 7 & 10 Operating System & Update Issues
    Replies: 0
    Last Post: Nov 23, 2019, 22:56
  3. Caution: Feature update to Windows 10, version 1607
    By Colin Haig in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 1
    Last Post: Sep 23, 2016, 13:43

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •