I've run into this problem before and the solution has usually been to restart IIS. Basically I've made a number of changes to a .wsc file on our server. But when it runs it doesn't run the new code changes I made. I've verified this with event logging at the beginning of the file and it doesn't show up.
My problem is that obviously restarting IIS on our production server is something I'm loathe to do, but we need this running today. I've tried re-registering the file but to no avail.
The server is a 32-bit Server 2008 OS. And the code is running, it still generates the file it is supposed to, but like I said, it's not using the latest changes.
Any other info I can provide, please leave a comment and I'll edit.
Thank you,
Jeff
Edit: Oisin, thanks for the reply and yes I know I hate VBScript, and anything related to it including these Window Script Components. I've expressed such feelings to my manager, but it's a dirty job and someone has to do it!
Yes it's using a Server.CreateObject to call the component.
ANSWER: I've since realized my mistake. I was only 'registering' it over and over, when I should have first 'unregester'ed it the 'register'ed it. Man I feel stupid, but haste makes waste as they say.
Thanks for the response and link!
Eek, you mean WSC as in a Windows Script Component? I haven't written one of them since 2000.
Are you loading it using CreateObject (e.g. it's registered as a COM object via regsvr32), or are you using a file-based moniker to load it? (not registered).
If it's registered, it probably is cached until app restart. If you switched to a file based moniker, e.g. like: Set o = GetObject("script:c:\path\obj.wsc"), you might get away with runtime changes to the .wsc file.
(man, how did I even remember this)
more info here - quick before it's archived! :D
http://www.microsoft.com/technet/scriptcenter/resources/scriptshop/default.mspx
-Oisin
Related
I have inherited a program written in VB 6 that is not working when the user tries to print. I had some ocx files I needed to register (regsvr32), which I found using Process Monitor, but I can't see where this error is coming from. Is it possible to find out what component the program was trying to create? This program was written by someone else and I don't have access to anything but the original setup program. Thanks.
So the issue was not the old program, but something to do with Access. I happened upon some articles dealing with this particular issue, but nothing worked. I had to install Access 2013 32 bit in order to make this work. I didn't really fix the cause of the problem, but I wanted to put this here to point any future sufferers they check Office and their program if they run into a similar issue.
HTH
Wade
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
I have a file which can be edited from several different places over an intranet, but needs to be kept up to date on one specific machine.
The way things work is like this.
We have a local intranet where changes to the file are made and viewed on the intranet copy of the live website. If everything looks good, the file may then be uploaded to the remote server, overwriting the previous version.
It isn't ideal, I know, but thats the way it has to be.
What I would like to do is keep track of any changes to that remote version of the file so I can then reflect that change on my local machine.
The idea I've had so far is to use the Task Scheduler on the remote server to send an email to me whenever a change takes place. Changes aren't foreseen to happen often, but when they do, I need to know about it.
My problem is, I'm not sure what events to look for in Task Manager. As it stands, the file could be changed by someone FTPing into the server and changing it or by someone remoting in and uploading that way. As I said, not ideal, but its what I have to work with.
To keep things specific, I'm looking to use Task Scheduler here, working off a trigger. From there, I'm a little lost.
As it turns out, I found a better/more useful/"good enough" solution, by creating a FileSystemWatcher and starting it when the application starts.
Thats where the "good enough" comes in, since it won't catch any changes if the application is stopped for some reason. However, since I'm the only one likely to stop the application, things will be a bit more serious than a broken FileSystemWatcher if it comes to that.
Specifically, I created a class called "Utilities" and created the FileSystemWatcher in there.
Then in the Global.asax.cs Application_Start() method, I initialised the FileSystemWatcher and set it going.
If a change takes place, the event handler of the watcher is set to fire off an email to me, with the new file attached.
Simples.
I have some code that is reading a config file, but when I open the file in TextPad, I see different values than my application does. I checked it with Notepad. Notepad agrees with my application, TextPad shows something else.
This is on Vista x64 Business.
Any idea what could be causing this? I've looked in the Context Menu->Properties->Previous Versions details, but it says "There are no previous versions available".
Here's the steps to replicate (I can't make it happen reliably):
Installed .NET app in Program files.
That app reads the config file, but is falling over.
I manually edit that config file in Textpad.
The change doesn't take effect.
I open the config file in Notepad, and see something different.
Try making the change in Notepad and saving, and get this error message:
Notepad
Cannot create the C:\Program Files (x86)\Daniel Schaffer\WorkingOn for FogBugz\FogBugz > WorkingOn.exe.config file.
Make sure that the path and file name are correct.
I can't put the content here as it's XML and is being encoded by Superuser.com, but here's a link to a screencast: http://screencast.com/t/zhERl7mocp4.
Sounds like a case of you don't have administrator privs, when you installed your app. Sometimes when you install an app with no admin privs, it behave really strangely because of vista security model. I had a similar problem to this last year. It wasn't the exactly, but it was strange behaviour, until I figured out it was vista's security model. It elevates it into application/user security context, from what I know, as my brain froze when I was reading about it, as it was pure muck and virtually useless from what I can see.
Try opening Textpad (excellent app) with Run as Administrator, and then edit the config. See what happens. If it stays then same then its a prives problem. If that doesn't work, deinstall you app, and then install it as an administrator. That will give the app the write admin privs to work. Then when you edit the config. See if that works.
Take a look at this. You can elevate an app to run as administrator, Using the techniques found here. How to elevate an application.. Try all these before you do a reinstall.
If that doesn't work, post your question to server fault. Also post it to a suitable MSDN forum.
Hope that help.
Bob.
This is interesting. My guess is that a Vista Feature called UAC Virtualization (aka Data Redirection) is at work here. It basically redirects legacy applications to %USERPROFILE%\AppData\VirtualStore\Program Files\... so they can write files in the program's directory.
Maybe Textpad tries to open the file in read-write mode while both your application and Notepad use it read-only?
You can fire up Process Monitor to see the exact magic, and please let me know ;-)
Try just to strip that whitespace character from application name; my guess is something related to canonical path building
try to copy file to another path and reopen it. see if it changes the result.
One thing you can do is observe what exact file each of those methods ends up opening. To do this,
launch Process Monitor from the sysinternal suite.
look only for file operations (deselect registry operations on the right of the toolbar)
select only your own process (filter out all the processes that you don't care about, or just include your own process name in the filter list)
You can also simply use the search function for your file name, this might be the faster route.
Process monitor has helped me find so many issues it's amazing.
Is there any "Boot session ID" or (reliable) "Boot timestamp"?
For an installation I need to detect that a scheduled reboot took place indeed.
I guess I could do a dummy MoveFileEx() with MOVEFILE_DELAY_UNTIL_REBOOT, but i did hope for something easier.
(We have to install a 3rd party package that sometimes behaves erratically after an repair/update. In that state, accessing the device may even lock up the system)
(Windows XP, Vista, 7)
For things like this, WMI (Windows Management Instrumentation) is often a good starting place. I know you can get current uptime directly through it, which may allow you to determine if a machine recently rebooted.
Here is a blog post with some code samples as well:
http://blogs.technet.com/heyscriptingguy/archive/2004/09/07/how-can-i-tell-if-a-server-has-rebooted.aspx
Depending on your implementation language, you probably just want to pull out the query code from the vbscript.
Apparently Windows has the equivalent of "uptime". Here's more info: http://support.microsoft.com/kb/555737
As I understand it, this should tell you how long ago the system was booted. Will that information solve your problem?
You could search the System event log for event 6009 from the EventLog source - this is the first event recorded after each reboot.
I think the best answer has already been given here: Find out if computer rebooted since the last time my program ran?
That seems to be the simplest way. Use GlobalFindAtom() to see if it exists and create it, with GlobalAddAtom(), if it doesn't. It will persist beyond the execution of your program. If your application runs again, and sees that the atom exists, then then it isn't the first run since reboot.
If the computer is restarted, then the atom won't exist, indicating that this is the first run of your program since the reboot.