Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Winoldapp

Status
Not open for further replies.

gnosis13

Programmer
Jul 13, 2001
263
US
I have 2 programs that start from the startup folder. They both run in DOS boxes. One of the programs fires an executable that reboots the machine (95 & 98). Sometimes this works, sometimes not. About 1/3 of the time, a Winoldapp error is generated. I have tried all of the properties settings on the DOS box with no consistent results. Is there a patch or something available for this? Anyone know how to fix?
 
It seems unreasonable if under exactly the same cirumstances 67% of times you have no problem whereas 33% of times you have. So, to determine where the problem is, you should disclose more.

Nevertheless, I have some idea as to what the problem might be and the problem probably comes from the executable you use under the dos box to reboot the system. The winoldap stands in between and may hinder the proper functioning of it.

Without your further input yet, I would suggest you to do the following. Instead of using a 3rd party executable, and as you are in windows shell already, you can use the following line to force the system to reboot :

RUNDLL32.EXE shell32,SHExitWindowsEx 6

replacing the line calling the executable in question. This is for win98. Equivalent line exists for win95 using rundll.exe. Also, the pif of your batch should be set to allow the batch to see the windows background. Furthermore, if your system is in on a network, then precaution has to made to prevent unwarrented reboot provoking data loss.

regards - tsuji
 
Thank you for the excellent advice. However, I do not have access to the command line. These two programs work together. One gathers scans from a bar-code scanner, the other transfers the scans to a server. At midnight, the transferring program calls another program called Winboot, then halts. Winboot reboots the machine. The scan gathering program never gets stopped clean, it just goes down when the machine reboots. I am pretty sure this is what causes the problem, however, I have no idea why it is not consistent.

The transfering program has a memory leak which will cause it to eventually lock up without the reboot. I do not have access to the sourcecode so I am stuck either patching the machines, or rewriting the Winboot program. I think if I can get Winboot to close both programs clean before rebooting, I will be ok. I am struggling to get a program running that will work so I thought I would try some "tech" advice.
 

I recently scanned my computer and discovered I had a virus. It was infecting only one file (UO2001.EXE in my windows folder.)

When I attempted to delte it it would tell me that the file was in use or write protected. So I deleted it from DOS.

Now I can not open any Applications on my computer, it says that I must have this UO2001.EXE to open. Is there some way to fix my problem other than reformatting?
 
Hello, Choctaw.

Worrying about you have not got what I meant, I add a note here.

The rundll32 line is there to replace the part in your batch file(s) which is intended to trigger a system reboot. I did not mean you have to access the command line and physically enter the command there at some point of time during the execution of the batch files. With it scripted into the batch file(s), it is fully capable to be branching to a force reboot according to the events within the logic already scripted in your batch files.

Hope this clarifies what it means.

regards - tsuji
 

oops did not mean to post that into this thread should have been its own. Sorry
 
Thanks again, I am looking at your suggestion. I have to set up a new test machine.....may take a while.
 
Necroscope, I have not seen your posting when I post the above. But, you have an entirely different problem. It is a virus recovery problem. So I would suggest you open a new thread to get proper help. Sure you will get good help.

But before you doing that, it seems to me that you've got some trojan-type which modifies your registry on the execution of .exe file. So the minimal work you have to do after you deleted UO2001.exe :

[0] Boot to command line (ie DOS).

[1] Use edit.com to inspect win.ini and system.ini. In particular, look at run or load lines, and comment out suspicious line.

[2] Create the following file, called it buildexe.reg with the extension "reg".

----------below this line---------
REGEDIT4

[HKEY_CLASSES_ROOT\exefile\shell\open\command]
@="\"%1\" %*"

[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\open\command]
@="\"%1\" %*"

------stop above this line-----------

[3] At command prompt, enter the command below :

regedit.exe buildexe.reg

(you have to supply proper path if necessary.)

[4] If the import is successful, then reboot to windows.

The above may be crude. If you post an new independent thread, I am sure there are many helpers out there.

In any case, after your system is up again, check virus centers for exact info on your virus and see if there is something more to do to 100% clean it up. Also, change your passwords you use thereafter.

regards - tsuji
 
Choctaw,

If regedit is disabled, you can use the following .inf file. Copy and paste the text between the lines and save as fixregexe.inf. Do this on another computer and transfer it by floppy. Right-click and choose install.

==================BEGIN CUT==========================
[Version]
signature=$CHICAGO$

[DefaultInstall]
AddReg=EnableRegandexe

[EnableRegandexe]
HKCR,\.reg,,,"regfile"
HKCR,\regfile,,,"Registration Entries"
HKCR,\regfile\DefaultIcon,,,"C:\WINDOWS\regedit.exe,1"
HKCR,\regfile\shell,,,""
HKCR,\regfile\shell\open,,,"Mer&ge"
HKCR,\regfile\shell\open\command,,,"regedit.exe %1"
HKCR,\regfile\shell\print,,,""
HKCR,\regfile\shell\print\command,,,"C:\WINDOWS\NOTEPAD.EXE /p %1"
HKCR,\regfile\shell\edit,,,"&Edit"
HKCR,\regfile\shell\edit\command,,,"C:\WINDOWS\NOTEPAD.EXE %1"
HKCR,\.exe,,,"exefile"
HKCR,\.exe,"Content Type",,"application/x-msdownload"
HKCR,\exefile,,,"Application"
HKCR,\exefile,EditFlags,1,D8,07,00,00
HKCR,\exefile\shell,,,""
HKCR,\exefile\shell\open,,,""
HKCR,\exefile\shell\open\command,,,""%1" %*"
HKCR,\exefile\DefaultIcon,,,"%1"
=============END CUT==================

I've had good luck replacing the winoa386.mod file in the c:\windows\system directory. Use Winzip or similar to extract a file named winoa386.new from the cab files on the original CD or
c:\windows\options\cabs if avaulable. In Win98SE, the file is located in the c:\windows\options\cabs
\WIN98_51.CAB file. After extracting, rename the file to WINOA386.MOD and move it top the C:\WINDOWS\SYSTEM
directory overwriting the file that exists there now.

The C:\WINDOWS\SYSTEM\WINOA386.MOD files internal name is Winoldapp.

reghakr
 
Hello reghakr.

Regret the confusion. Two of my postings above concerning the trojan were directed to Necroscope, rather than to the proper owner of this thread Choctaw. Hence your very good posting should be divided into to parts, one for Necroscope and one for Choctaw.

I have some notes to add on to your posting though.

[1] trojan part for Necroscope

[1.a] The .inf seems to accomplish tasks more than it calls for. It rebuilds, for one, the .reg, as well as .exe association. Second, I don't think it coincide the trojan's scope of damage to registry. In other words, it could overkill and modify the user's legitimate registry tweak. This is critic toward a learned. (Others may not understand the idea of rigor of and what's behind a professional troubleshoot, but, I think you understand.) But, I like your inf, though.

[1.b] A flaw in using ".inf install" or ".reg open" in the windows environment proper is that it calls for rundll.exe or regedit.exe. And, this may, but not necessarily, be trapped in the same vicious circle---and that 's why the idea of renaming regedit to com. Whereas, if regedit.exe is not damaged itself, it can be done in real DOS command prompt.

[2] Winoldap part for Choctaw

[2.a] You know well what it involves. Nevertheless, I had not raised the issue of replacing a fresh copy of winoa386.mod (with the footnote of winao386.new etc.) is that Choctaw's batch files seem to run. Also, that no hint is made that he has any trouble in opening up a dos box or running any 16-bit application. Hence, I did not find any reason to raise that possibility fear of wnwarrentedly complicating the issue.

[2.b] I might have suggest a killing of process which I believe is "standing between" a proper reboot. Using a win resource kit utility like kill.exe will do---"kill /f winoa386", for instance---to remove the obstacle. But, thinking about synchoronous and asynchronous of the matter, I reserve it as an alternative out of many, in case Choctaw has not correct the problem.

In any case, the vague issue raised by Choctaw may end here pending for the forum. Not much info is disclosed for a diagnostic to begin with,... With the above notes, I may call a halt to my contribution. Be assured my respect, reghakr.

regards - tsuji
 
tsuji,

You're right, I didn't see that there were two posters up untill your very last comment. I thought Choctaw was having additional problems.

Thanks, I did forget about the regedit.com renaming trick.

Regarding the fixregexe.inf, there is no DelReg= section in the .inf file, so it won't remove any modifications the USER may have made. The trojan acts on the known "default" settings and that's what the .inf file does. It restores those default settings.

Keep up the good work, you are OBVIOUSLY a very talented technical user.

reghakr
 
tsuji, rehakr,

Not much help for my problem, but your advice for Necroscope is some pretty cool stuff.....got a hardcopy for my file!

Thanks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top