On our RDS hosts, we run a custom made (vb.net) menu system that allows our users to shell other apps we wrote. So basically it's a vb.net app that shells other vb.net apps. This worked for many years, but since a few months, we noticed that something strange... after a user opens acrobat reader, all the apps that are shelled from our menu app get low integrity level, causing them to fail. All the user can do to fix this, is log off and then log on again.
Oh, we even have some VB6 apps in our menu (I know...) and they have the exact same issue.
Process Explorer screenshot
I've tried reading up on all this integrity mechanism stuff, but I don't see any reason for this behavior. Here's the code that shells an app:
Dim PSI As New ProcessStartInfo
With PSI
.Arguments = Arguments
.WorkingDirectory = WorkingDirectory
.FileName = Executable
.UseShellExecute = True
End With
Dim P As Process = Process.Start(PSI)
'Executable: "C:\Program Files\<path>\<appname>.EXE"
'Arguments: "/NET=BHDMGR /USERLEVEL=3 /SYSLOG=False"
'WorkingDirectory: "C:\Program Files\<path>\
Any hints about how to debug this, are very welcome!
Related
So it looks like Windows 10 Ransomware has broken my app (StationRipper). It's a C++/MFC app, but it looks like it would break any app that is doing what StationRipper is doing.
My high-level question:
My app needs to write files (e.g., mp3's) as it records them. Is there actually a sensible place do this to (like, say, the Music folder) if Ransomware protection is on, or am I stuck just creating an arbitrary folder someplace? My app is doing the recording behind the scenes, so the user can't choose the dir for each file.
Details:
My app records music files. A very long time ago (like, in 2002) it wrote it to the users "Music" directory. That worked fine, but now I'm seeing a problem - I'm getting the error code for "The system cannot find the file specified." on CreatedDirectory for my app (which was really fun to track down, as that error code isn't listed as an error that CreateDirectory to return), and when I try to write any file to that directory if I manually create it via file explorer.
I finally tried running mkdir, and to create a file in that dir, outside of my app... the same thing happens.
I turned off Ransomware protection in Windows Defender... and it now works from my app.
It looks like I have to use something like the file picker to save to that dir? Which, as I said, won't work as the user isn't involved after they start recording.
I can't just tell my users to turn Ransomware protection off to use my app, but I would prefer to put the music files in their Music folder...
Any suggestions?
Additional info requested in comments:
TCHAR szDocPath[MAX_PATH];
szDocPath[0] = 0;
if (::SHGetSpecialFolderPath(NULL, szDocPath, CSIDL_PERSONAL, FALSE))
{
_tcscat(szDocPath, "\\StationRipper");
DWORD m_dwLastError = ::GetLastError();
BOOL bResult = CreateDirectory(szDocPath, NULL);
m_dwLastError = ::GetLastError();
}
Running the above with Ransomware protection on results in a zero. With it off returns a 1 (and the directory is created).
(note: SHGetSpecialFolderPath is not supported, but its modern equivalent, SHGetKnownFolderPath has the same issue)
Rather than asking users to disable Ransomware Protection entirely, you can ask them to whitelist your application. See the Whitelist apps with Controlled folder access section of this article (the official documentation is somewhat lacking).
I have to debug a classic asp site being served by IIS 7 (windows 2008).
How can I do this? I have only worked with ASP.NET.
From an MSDN blog post: http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx
Here is how to make ASP debugging work:
Enable ASP debugging on the server. (I also added DEBUG verb to the asp extension, but I am not sure if it is required).
Open classic ASP in VS 2005.
Set breakpoint.
View page in browser or run without debugging.
Debug | Attach to Process
Locate IIS ASP worker process (w3wp.exe on IIS6) which exposes x86 and Script and attach as Script.
From eddiegroves comment below:
Regarding Step #1 in IIS7 - IIS > ASP > Compilation > Debugging Properties > Enable Server-side Debugging
I realize this is old, but thought I'd reply to help others since I was looking something else up.
You can use Visual Studio to debug Classic ASP.
If you're running a local copy of IIS, just attach the debugger to the w3wp.exe process and you can set breakpoints, add variables to watch windows, etc.
If you have more than 1 website, it's helpful to run each in a separate application pool, and you'll be able to identify different w3wp.exe process in the Attach Process window.
Just choose "script" as the debugger type. If you're running IISExpress, then the iisexpress.exe process is the correct one to attach to.
I've found that a useful setting to enable is found at the server level under ASP > Compilation > Debugging Properties > Send Errors To Browser. Set that to "True".
This may not be appropriate under all circumstances (e.g. for an internet-accessible site).
Built in classic ASP debugging is pretty poor. I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.
https://github.com/dmeagor/ClassicASP-FirePHP
Released under MIT open source license
This is the way I figured it out:
Put a stop (write stop) on the place where you want to hit the debug point. Then run the application on browser. When the execution comes to stop it will open up debug popup asking do debug with Visual studio (a VS version must be installed). Then it will ask to attach the process and you can use f10, f11 to go step over and in. You can see the data using add watch.
I use the following (which I got from somewhere online) to write to a log file. I would prefer a method for writing directly to Console in Firefox or Chrome, but this works pretty well for me.
NOTE: "timestamp" is a custom function of mine. You can probably guess what it does, and probably roll your own. ;-)
function error_log( message )
dim objFSO, objLog
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objLog = objFSO.OpenTextFile( "ASP_errors.log", 8, true)
objLog.WriteLine "[" & timestamp & "] VBS Message: " & message
objLog.close
set objLog = nothing
set objFSO = nothing
end function
host your site on IIS server.
enable remote debugger on IIS server.(follow this tutorial)
import the source code into visual studio.
install remote debugging tool from here
In the remote debugging tool select tools-> options -> no authentication for all users.
Go to visual studio and attach to process w3wp.exe.
if cant see the process (w3wp.exe). Open the website link in browser and select show for all users
now u will be able to see the process and attach.
Dont forget to put a debugger in the application :-)
I'm automating some reports using visual basic. I've recorded some scripts that worked fine by seem to have stopped working for reasons unknown. I record the following (comments added) and the script fails at a file dialog box.
session.findById("wnd[0]").resizeWorkingPane 95,22,false
session.findById("wnd[0]/tbar[0]/okcd").text = "se16"
session.findById("wnd[0]").sendVKey 0
' Run AGR_TCODES
session.findById("wnd[0]/usr/ctxtDATABROWSE-TABLENAME").caretPosition = 10
session.findById("wnd[0]").sendVKey 0
'Select Extended Name, Multiple selection
session.findById("wnd[0]/usr/btn%_I3_%_APP_%-VALU_PUSH").press
session.findById("wnd[1]").sendVKey 23
' select file
session.findById("wnd[2]/usr/ctxtDY_PATH").text = "c:\my_directory\"
session.findById("wnd[2]/usr/ctxtDY_FILENAME").text = "myfile"
session.findById("wnd[2]").sendVKey 0
Its at this point in script playback that the script just stops with the file select text inputs blank. I can type the information in, but that kinda defeats the purpose. I can't find the reasons or a cause, but lots of various upgrades have occurred, including my laptop and a reinstall of the os to WIN10. I don't really care why - but I do need to find a way around it.
There are 2 scenarios I've identified:
It appears that SAP occasionally loses the focus of dialog boxed. Use gratuitous .setfocus commands on the window to compensate
It appears that uploads via scripts may be blocked by security settings. You can do it manually, but not via script. A telltale sign is that when you record the script, your inputs are not recorded. So the DY_FILENAME.text line will be completely missing from the recording. I'm not sure how to fix this, but at least you know where to look!
Good luck with your scripts.
I have an issue with an auto start of Outlook 2016 at boot/log on which is intended to start Outlook minimised to the Windows system tray, such that once invoked at Windows 10 launch mail will be collected by the mail account(s) (NB. All POP in this case.) whilst the program resides in the system tray remaining invisible until required by the user.
The .vbs script below does function as required but much of the time it introduces two unwelcome issues.
The Outlook icon in the System Tray displays a 'cog' overlay with the message "Another program is using Outlook. To disconnect programs and exit Outlook, click the Outlook icon and then click Exit Now".
Attempts to open Outlook from the 'Open Outlook' context menu (right click Outlook icon in the tray) item causes a dialogue box to appear reporting "No active explorer object found". Clicking the "OK" option in response launches Outlook (though issue 1 - cog overlay) remains.
Neither issue is present when Outlook is started normally from the desktop so it would appear that the .vbs script is in someway responsible. I have used this script successfully (see also below: https://superuser.com/questions/467809/start-outlook-automatically-in-tray) in the past both as a startup menu shortcut and a hkcu 'run' registry entry.
Can anyone suggest the cause or alternately a suitable code revision to achieve correct function? In case it is significant, Windows 10 is 64 bit Pro and the version of Office (including Outlook) installed is also 64 bit.
This is the code invoked by the .vbs script:
OPTION EXPLICIT
OPTION EXPLICIT
CONST PATH_TO_OUTLOOK = """C:\Program Files\Microsoft Office\Office16\OUTLOOK.EXE"""
CONST SHOW_MAXIMIZED = 3
CONST MINIMIZE = 1
DIM shell, outlook
SET shell = WScript.CreateObject("WScript.Shell")
' Open Outlook
shell.Run PATH_TO_OUTLOOK, SHOW_MAXIMIZED, FALSE
ON ERROR RESUME NEXT
' Grab a handle to the Outlook Application and minimize
SET outlook = WScript.CreateObject("Outlook.Application")
WScript.Sleep(100)
outlook.ActiveExplorer.WindowState = SHOW_MAXIMIZED
' Loop on error to account for slow startup in which case the
' process and/or the main Outlook window is not available
WHILE Err.Number <> 0
Err.Clear
WScript.Sleep(100)
SET outlook = NOTHING
SET outlook = WScript.CreateObject("Outlook.Application")
outlook.ActiveExplorer.WindowState = MINIMIZE
WEND
ON ERROR GOTO 0
SET outlook = NOTHING
SET shell = NOTHING
Having spent a number of hours on this issue over the weekend I thought that I had resolved the issues and got everything functioning as intended.
Working from similar samples of code I compiled a new script (see below) which I applied both as a shortcut in the Startup folder and also as an entry into the 'run' branch of the HKCU registry.
Now for the issue! Testing the script on two separate Windows 10 Pro (both 64 Bit architecture) systems both with Outlook 2016 64 Bit installed as part of a 64 Bit Office suite I found that whereas on one system the script runs flawlessly on the other I receive the following runtime error:
Script: D:\Neil's Files\Neil's Filing Cabinet\Neil's Emails\Start Outlook Minimised to Tray\Start Outlook 2016 Minimised To Tray.vbs
Line: 11
Char: 5
Error: ActiveX component can't create object: 'GetObject'
Code: 800A01AD
Source: Microsoft VBScript runtime error
This has me perplexed as the script file and it's related shortcut are both physical copies of each other given that the revised script below contains no path references (as these are handled directly by the code in respect of Outlook.exe) which are identified by the placement of either the shortcut or as the data element of the registry string whichever format is used.
The Systems do have some differences however and for comparative purposes I will summarise those I feel to be relevant here:
System 1: (The problem system) is an X58 Asus P6T7, Intel i720 mature PC with many programs installed and specifically the Outlook 2016 has the same 12 addins installed but in addition has two related programs which launch at boot, the enterprise editions of 4team's Sync2 for Microsoft Outlook and Safe PST Backup. The boot times are quite lengthy (but acceptable) as is the Outlook Startup with it's various addins.
System 2: Is a current generation Asus X99-Deluxe, i7 5930 new build pc with little installed as yet save MS Office, Adobe CC and some utilities.
In the case of System 1, Outlook auto-starts as intended however during it's loading splash screen (whilst it is loading up the addins) the runtime error is displayed although Outlook continues to open fully but fails to minimise.....
This suggests to me that the faulting code is the section which activates the window however the above error message refers to "ActiveX component can't create object: 'GetObject'" which suggests instead an issue with the code line "Set OLObj = GetObject("","Outlook.Application")"??
Hopefully somebody can test the code on a similar setup and report back? Or alternately, give me a pointer as to what is going on and how I might resolve it. I would of course also welcome any suggested improvements to the code!
** Quick Update ** Now tested on HP Elitebook 8440P Laptop - Windows 10 Pro 64 Bit with Office 64 Bit + same 12 Outlook Addons - Functions as intended.....
** Further Update ** Tested on a second HP Elitebook 8440P Laptop - Windows 10 Pro 64 Bit with Office 64 Bit + same 12 Outlook Addons - Above RunTime error experienced once again.......struggling to comprehend why these results are occurring?? Any thoughts anybody???
The code below is offered "as is" for the benefit of anyone else seeking the same Outlook auto start criteria. The testing with System 2 indicates that it works so I hope others enjoy similar success until the outstanding issues are sorted.
NB: To adjust the Outlook Launch Window Size (during its 10 second pause prior to automated minimising) to reflect personal preferences change the numeric value in the following line of code:
WshShell.Run "OUTLOOK.EXE" , 3, false
For a maximised window size change the value to 3 For a restored window size change the value to 2
OPTION EXPLICIT
Dim WshShell
Dim OLObj
Set WshShell = WScript. CreateObject ( "Wscript.Shell" )
'Open Outlook: Note that inspite of the launch options, it will open the program in a normal window.
'The file location path is not necessary as Windows 10 correctly identifies Outlook's location.
WshShell.Run "OUTLOOK.EXE" , 3, false
'This will mimimise it to the system tray after a 10 second pause to allow for mail collection on Outlook launch.
WScript.Sleep (10000)
Set OLObj = GetObject("","Outlook.Application")
'Activates the window
OLObj.ActiveExplorer.Activate
'Sends the command to minimise
OLObj.ActiveExplorer.WindowState = 1
'Outlook does not immediately minimise to the system tray so that 'Send/Receive' can initiate mail collection.
Thanks to jrv from Microsoft's "The Scripting Guys" forum who kindly offered a revised (simplified) code which is below. I can report that as with the original code it works flawlessly on the same 2 systems as before, whilst faulting once more on the other two......very much perplexed!!
The Runtime Error:
Script: D:\Neil's Files\Neil's Filing Cabinet\Neil's Emails\Start Outlook Minimised to Tray\Start Outlook 2016 Minimised To Tray.vbs
Line: 3
Char: 5
Error: ActiveX component can't create object: 'Outlook.Application'
Code: 800A01AD
Source: Microsoft VBScript runtime error
The revised code:
Set WshShell = CreateObject ( "Wscript.Shell" )
WshShell.Run "OUTLOOK.EXE" , 3, False
Set ol = CreateObject("Outlook.Application")
ol.ActiveExplorer.Activate
ol.ActiveExplorer.WindowState = 1
You can use like file *.reg:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"Outlook"="C:\\Windows\\system32\\cmd.exe /c \"start \"\" /min \"C:\\Program Files\\Microsoft Office\\Office16\\OUTLOOK.EXE\"\""
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences]
"MinToTray"=dword:00000001
I have an answer that works well with Office 2013 on Windows 7, and I hope it works for you too.
Essentially, this solution bypasses the issue with trying to force Outlook to minimize after loading. Instead, it relies on using a shortcut that's already configured to load the program in a minimized state.
Copy a shortcut to Outlook into the directory containing your script.
Right click the shortcut and open Properties.
In the Shortcut tab, change the Run mode to Minimized. Press OK.
Then, all you need to do in your VBScript file is to execute the shortcut like so:
Dim sh : Set sh = CreateObject("WScript.Shell")
sh.run "Outlook.lnk"
Note that because this solution uses a shortcut, you could potentially remove the VBScript part entirely by putting the shortcut into the All Users Startup folder.
It's me again! I have an answer that should bypass any issues with VBScript by using third-party software, DisplayFusion. I don't know how you'll feel about that, but I tested it and it works over here. I use this at home and at work to manage multiple monitors and various other things. It may even help solve problems with other programs you use and render various VBS hacks redundant.
In your case, there is a feature called 'Triggers'. Note that while there is a free version of DF, you'll have to activate a 30 day trial for the Pro version to use Triggers, and after that, it's up to you to decide if it's worth your while.
Firstly, after installing DF, you'll want to open up its settings window (right-click desktop and go to DisplayFusion > Settings).
Go to the Triggers tab and click Add.
Set up the trigger for when a window is created. Tell the trigger to activate only once per process ID so it won't also try to minimize subsequent windows, such as when composing a new email. Find the path to your outlook.exe. Then, add an action on the right-hand side to minimize the window.
Click OK twice and then see if it works by loading Outlook. For me, the splash screen appears as normal, then the main window is minimized as soon as it appears.
DF runs as a system service with admin privileges and has been tested with tonnes of software packages, so if this method also fails for you, it could indicate bigger issues with your system/Office configuration.
I have a VB6 application, the installer is compiled using INNO Setup.
The installer runs fine. But in about 10% of computers when the user clicks the Icon to run the installed app, it doesn't start, no error message, only a Beep sound.
This is happening on XP and also Win 7.
I develop in XP and Win 7 and the application works OK, so I haven't been able to reproduce the issue.
The installer registers all ocx and dlls needed (afaik). (Well not completely all, it assumes MS run-time components should be there, but I guess an error message should show up if something is missing)
I was thinking some kind of user permissions, UAC, but even users in the admin group have had the issue.
Could you point me to what possible issues to look for and test in order to patch the app.
Thanks!
[FOLLOW UP]
Thanks to the tips, found out the manifest is causing the problem. I use it to make the controls look better:
http://www.vbaccelerator.com/home/vb/code/libraries/xp_visual_styles/using_xp_visual_styles_in_vb/article.asp
Now I'm trying to discover why. I have another application with the same manifest and that one works ok.
Haven't been able to get feedback on the event viewer yet.
The "beep crash" often points to an error in an application manifest such as an XML syntax error or namspace conflict. Event Logs will often provide a hint about this.
But I've found that people often try to use the Common Controls 6.0 Library without ensuring proper library loading sequence.
Before any Forms are openend you should load shell32 and then comctl32. The easiest way is a couple of no-op calls in Sub Main:
Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32" ()
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
Private Sub InitCommonControlsVB()
IsUserAnAdmin
InitCommonControls
End Sub
Private Sub Main()
InitCommonControlsVB
Form1.Show
End Sub
Without this your program will usually work fine in Vista or Win7, but will fail on some XP service pack and patch levels. Part of this is due to changes over time in the Fusion subsystem that handles SxS activation and comctl32.dll patches.
Ignore those saying you need to call InitCommonControlsEx(), it isn't necessary unless you are constructing and using Win32 controls directly instead of VB6 and COM controls.
A few things to try to narrow it down:
Check the Windows Event Log for crash events
Check the Windows Event Log (in the Application section) for crash reports from your application. You can quickly get to the log viewer on Windows XP by clicking Start > Run, typing eventvwr and pressing Enter. On Windows 7, you can type "event viewer" in the search box that is in the Start menu. You can filter the events to only show error events from your program.
You might find a few error events on one of the computers where this problem has already occured, because it sounds like the error reporting feature is turned off on these computers (in which case "hard crashes" like access violations are logged in the Event Log instead of displaying an error dialog to the end-user, as long as a debugger isn't installed on the computer).
Make sure "Error Reporting" is turned at the OS level
As mentioned in the previous section, it sounds like the error reporting feature is turned off on these computers. In that case, a crash won't display any kind of message to the end-user at all and the application will just vanish suddenly. In Windows XP, you can check this setting (and turn it on) as follows:
Right-click "My Computer" and select Properties.
Open the Advanced tab and click the Error Reporting button.
Select the Enable Error Reporting option.
Click OK to all the open windows.
Add trace code to your application
You could also add some trace code to your application's start-up code, such as code to display a message box or write a message to the Windows Event Log or to a log file as soon as your application starts (for example, in the Form_Initialize event of your main form, or in a Sub Main routine).
This way you will be able to tell whether your application is crashing before or after the VB6 runtime is loaded: if you try to start the application and it disappears/crashes, and your startup message isn't logged, then you know it's crashing before it even has a chance to get to your application's startup code, which could indicate that a dependency of the VB6 runtime or the VB6 runtime itself is not installed properly.
Note that Windows XP and Windows 7 both ship with the VB6 runtime pre-installed, but it's possible for misbehaving installers to overwrite or remove files that are part of the VB6 runtime.