Jump to content

NVidia Video Driver Shutdown Fix

rloew

By rloew
in Windows 9x/ME

 Share

Recommended Posts

rloew

rloew

Posted
  • Author
Posted

@ RLoew. After a few days of use in one of my systems (P4, ICH5, GeForce 6600 GT) the shutdown problem came back with the ME-extended code !

So on Monday I reverted back to the code of posting 44 and the system did perfectly shut down every time since then.

I have not changed/replaced any hardware in this machine.

The new code works fine in my other, older PC (AMD, VIA, 6200). Weird .....

Odd. I haven't seen adding the Message 4 bypass cause any problems even when it is not needed.

Also, I have no idea why it would stop working if it had worked for days.

Try the following:

Put back the triple Patch currently shown in Post #1.

If it brings back the Shutdown problem, change the second byte of the long Patch from 4 to 25h and see if that fixes it.

Link to comment
Share on other sites

Drugwash

Drugwash

Posted
Posted

@ RLoew. After a few days of use in one of my systems (P4, ICH5, GeForce 6600 GT) the shutdown problem came back with the ME-extended code !

So on Monday I reverted back to the code of posting 44 and the system did perfectly shut down every time since then.

I have not changed/replaced any hardware in this machine.

 

The new code works fine in my other, older PC (AMD, VIA, 6200).  Weird .....

Which driver version is installed on the faulty machine? This info is needed so I can adjust the code in the ini.

 

 

[...]

Put back the triple Patch currently shown in Post #1.

If it brings back the Shutdown problem, change the second byte of the long Patch from 4 to 25h and see if that fixes it.

 

Would that be the same code in sections 8b (98SE wide) of the patcher?

 

 

I've just released v1.5.2.2 which fixes a regression in the ini related to Win95 versions (code was erroneously moved from section 6a to 4a for driver v81.98).

 

I've also uploaded a separate test ini for Mikl. The code is in the Generic section. In the patcher select 'Private' from the dropdown, it should work.

Link to comment
Share on other sites
MiKl

MiKl

Posted
Posted

Hi guys, as suggested yesterday I switched back to ME-extended code. No problems until now.

 

But I am wondering why this problem keeps coming back on my Nvidia-systems but not on my ATI-GPU-PC ??

That one shuts down every single time for ca. 8 years now after installing all the patches/fixes I found through supportnet.de, msfn, mdgx, etc.

Link to comment
Share on other sites
rloew

rloew

Posted
  • Author
Posted

This suggests that you have an issue that is dependent upon something else.

It is possible that this may also be related to your reported need to Patch Message 25h.

When your system is shutting down properly, change the sixth byte of the long Patch from 25h to 4 and see if this brings back the Shutdown problem.

Link to comment
Share on other sites
  • 2 weeks later...
MiKl

MiKl

Posted
Posted

@RLoew. The shutdown problem came back again !!

So I tried to (re-)search all the tips and tricks about the Win98SE shutdown issue. Right now I am testing higher values for 'cachewritedelay' !

The setting was 2000 but I increased it to 4000. No issues since then.

Link to comment
Share on other sites
Drugwash

Drugwash

Posted
Posted (edited)

That's an interesting find but it may well be an isolated case.

I suppose you already found this topic and these details. Is the hotfix installed on your system (System\VMM32\IFSMGR.VXD v4.10.2225)?

 

Not sure if issuing a _flushall() CRT call from within the video driver on shutdown would be a good idea and even if it were, certain driver versions may not have enough free space for the code. But this is probably nonsense anyway.

 

Would it make sense adding a cache delay choice in the patcher?

Obviously it would only work for in-place patching and apparently only 98SE and ME would benefit.

 

 

(added link to MSDN article for _flushall API)

Edited by Drugwash
Link to comment
Share on other sites
MiKl

MiKl

Posted
Posted (edited)
Would it make sense adding a cache delay choice in the patcher?

 

I think this may be a good idea because not everybody is as crazy as we are spending hours to (try to) fix anything but on the other hand I seem to be the only one who had 'more' problems with RLoew's great patch !! So it may not be worth the effort but maybe he will agree to include it ?

By the way, I have IFSMGR.VXD v4.10.2227 from PC's service pack.

Edited by MiKl
Link to comment
Share on other sites
Drugwash

Drugwash

Posted
Posted

Well, I'll look for the best way to add this feature then. Everybody has the right to be happy and yet almost nobody cares for the few that just need something different. ;)

 

Now, I'm not sure where the newer VXD comes from originally and what are its actual changes as compared to the known official version. Ideally a few tests should be performed on your system with the official 4.10.2225 and a cache value of 2000ms and observe if the unwanted behavior continues to occur or not (unless you already did that).

This should make it clear whether the newer version is somehow faulty in regard to shutdown or not.

 

BTW, how large are the HDDs on the faulty machine?

Link to comment
Share on other sites
MiKl

MiKl

Posted
Posted

BTW, how large are the HDDs on the faulty machine?

 

Drugwash, if it is O.K. for you I would prefer first to test IFSMGR.VXD v4.10.2225 with cache delay 4000 because the HDD in this system is a 40 GB with only around 36% free space !!

Link to comment
Share on other sites
Drugwash

Drugwash

Posted
Posted

@Mikl: Any and all possible tests would be great, hoping to narrow down the cause(s) and maybe establish a few ideal combinations.

If we find out the newer VXD has no fault then it will only be a matter of cache delay value.

Otherwise file version detection would be required and specific cache values based on version.

Add to this the various possible HDD size ranges and here's the big picture. :)

 

@everyone: I'm having trouble getting SetupDiEnumDeviceInfo() and SetupDiEnumDeviceInterfaces() to return anything other than error 259 (ERROR_NO_MORE_ITEMS) in my 98SE (works in XP but that doesn't help).

Does anyone know any other safe way to detect all attached fixed physical drives under Win9x? That would be required for an automatic (default) setting of an optimal cache value on a per-machine basis.

Link to comment
Share on other sites
jumper

jumper

Posted
Posted

From MSDevStudio97 (VC5) help:

The GetLogicalDriveStrings function fills a buffer with strings that specify valid drives in the system.

...

Each string in the buffer may be used wherever a root directory is required, such as for the GetDriveType and GetDiskFreeSpace functions.

and

The GetDriveType function determines whether a disk drive is a removable, fixed, CD-ROM, RAM disk, or network drive.

Link to comment
Share on other sites
Drugwash

Drugwash

Posted
Posted

Thank you but what I need is physical drives not partitions and all the above are dealing with partitions.

I mean, user may have three HDDs mounted with a total of ten partitions. I need to detect three physical drives, total capacity of each of them, then match the partitions to their respective physical drives in order to determine total free space on each physical drive from their respective cumulated partitions.

In fact all I need is the largest physical drive with the lowest free space.

 

There may additionally be a problem with removable USB drives if somehow cache writing is enabled for them. But that is something that will have to wait, for now.

 

I've been looking at vwin32 and various VWIN32_DIOC_DOS_* parameters but haven't found a solution yet. Still working on it though.

 

Any idea why the SetupDi* APis fail under 9x?

Link to comment
Share on other sites
jumper

jumper

Posted
Posted (edited)

DeviceIOControl should do it, but needs a handle from CreateFile and the PlatformSDK (Feb.2003) says:

"Windows Me/98/95: You cannot open a directory, physical disk, or volume using CreateFile."

This is likely the reason SetupDiEnumDevice* is failing on 9x.

But we can send control codes directly to VxD's such as VMM32.vxd and IFSMGR.vxd:

Calling DeviceIOControl on Windows Me/98/95

edit: Waybacked the link

Edited by jumper
Link to comment
Share on other sites
Drugwash

Drugwash

Posted
Posted

Yeah, I've bumped into that CreateFile() brick wall already. :( I knew about the vwin32 trick (as mentioned above) but couldn't find relevant info on enumerating physical disks.

Wasted the day trying with QueryDosDevice() (and obviously failing), now struggling with cfgmgr32 CM_* APIs - found out I already had built an incomplete wrapper for those APIs. Dunno if I'm going anywhere with that either. Turns out I have an incomplete/outdated environment which misses definition for PPNP_VETO_TYPE referred in cfgmgr32.h so I can't modify/build a demo code found on CodeProject.

It's been a long bitter day. See y'all tomorrow (according to my timezone). Thanks for all the help so far! ;)

Link to comment
Share on other sites
MiKl

MiKl

Posted
Posted

Hi Drugwash, wouldn't it be much more easier and flexible if you'll just add an option - maybe as a dropdown menue with values from 2000 to 8000 in steps of 250 or 500 - to your patcher ??

I mean, one system may still have shutdown problems with 4000 msec but not any longer with 4500 msec or whatever !!

So anybody who do not dares to touch the registry can increase "CacheWriteDelay" step by step until the perfect value is found.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...