13 replies to this topic

[Olof Lagerkvist]

Hi,

 

I would suggest that you temporarily disable the auto-creation of your RAM-disk and reboot. Just a guess really, but sometimes, even if you dismount a virtual disk, there may remain references in other drivers or applications. That means that the device cannot be fully dismounted. As long as there are references to the ImDisk driver, it cannot be successfully upgraded. Even if you manually stop a driver that is in use in some way, Windows won't let you start it again, upgrade it or practically do anything with it, until next reboot. So, if you disable creation of the device, there will never be anything that references the ImDisk driver and it should be possible to upgrade.

 

Another way could be to manually delete imdisk.sys from drivers folder before upgrade. This is possible even if the driver is in use, but it would require a reboot to get the new version loaded. You could also do the same with imdisk.exe and imdisk.cpl in system32 and syswow64 folders, but in that case a reboot would not be needed for new versions to be used.

[Olof Lagerkvist]

Both methods were failed.

 

My system is Windows 7 Home Premium x64 SP1.

 

 

First during installation process i've got error message:

 

 

And next this:

 

 

ImDisk remain in old version, or, in second methode, unnistalled.

 

It looks like something goes wrong with the Setup API. The first dialog is probably displayed by setupapi.dll because it is in Polish and there are only English messages displayed by ImDisk setup package itself. The message is of course displayed in response to something. Question is what exactly that could be. It is at least not something that is reported back to ImDisk setup as an error code or something like that, because ImDisk setup seems to think that driver setup was finished successfully.

 

For example, there could be some remains of an old version hiding in Device Manager or something like that. This could sometimes cause all sorts of strange behaviour in Setup API/PnP/Device Manager. Or something entirely else. Check if you get any .log files in C:\Windows that could give any clues!

[Olof Lagerkvist]

Strange. It says that the setupapi.dll operation was successful, even if it has displayed an error message.

 

I seem to remember that there is a verbose level for this log to be set somewhere. Probably a registry setting. I will try to find some info about that (or does someone else remember this better than I do?).

[Olof Lagerkvist]

It looks really strange. For some reason, it fails when committing the file copy queue. Reason seems to be related to backup of existing files of some kind. Just had a quick glance at the log though, I might be missing something. I have unfortunately very limited time at the moment, but just to try something, you could try to manually delete all files related to ImDisk and run the setup package again. The related files are:

C:\Windows\system32\drivers\imdisk.sys
C:\Windows\system32\drivers\awealloc.sys
C:\Windows\system32\imdisk.cpl
C:\Windows\system32\imdisk.exe
C:\Windows\system32\imdsksvc.exe
C:\Windows\syswow64\imdisk.cpl
C:\Windows\syswow64\imdisk.exe

[Olof Lagerkvist]

Still don't work.

 

Does manual replacement of ImDisk files is enough for proper update?

 

Yes, that should be fine.

 

The only problem could be if you have tried to uninstall ImDisk as part of any attempt to solve the upgrade problems. In that case, the uninstall process might have removed some of the driver/service registrations. There are various ways to manually re-register them though, for example using the sc command line tool. But to start, you could try to simply replace all files, reboot, and see if that works.

[Olof Lagerkvist]

Manual replacement worked.

Great!

[ady]

I know the original issue was resolved already, but maybe the following might be of some help in the future(?).

Manually replacing certain files in certain directories (such as “c:\windows\system32\”) is frequently not possible without some additional acquired permissions or tweaks.

Having the possibility to manually replace those files, in addition to having problems when (un)installing and/or upgrading programs, “sounds” like some “Take Ownership” issue. Abusing from “Take Ownership” tweaks can sometimes generate (un)installation problems.

Of course, I don't know if this was what happened in this particular case. It is just one possible reason.