Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×


  • Posts

  • Joined

  • Last visited

  • Days Won

  • Donations

  • Country

    United Kingdom

Radish last won the day on September 10 2018

Radish had the most liked content!

About Radish

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

2,682 profile views

Radish's Achievements



  1. I haven't been able to pin-down what launches the CameraHelperShell.exe (other than the 'auto-launch' setting in LWS mentioned above). I had a look in services but I didn't see anything there that references the 'Shell'. At one point in time I thought it was LWS.exe that launched the 'Shell' but I subsequently found out that it wasn't that. LWS.exe, if you let Logitech have their own way, gets launched at system bootup via an entry in the registry -- this means that the user has a process running that they really don't need to be running unless they're actually using the camera. So if you don't want that to be happening then make a reg tweak file of this and then merge it into the registry (this will stop LWS.exe from being launched at bootup): Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run] "LWS"=- That tweak just deletes the "LWS" entry from the registry. If you want to restore that then make a reg tweak of this and merge it. (This will restore having LWS.exe being launched at bootup. Important Note: you will have to adjust the path in the tweak to suit where LWS.exe actually exists on your system -- the double-back slashes are important, be sure to use them in the path you enter into the tweak.): Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run] "LWS"="C:\\Program Files (x86)\\VIDEO\\Logitech\\LWS\\Webcam Software\\LWS.exe -hide" I deleted the "LWS" value from my own system and then tested for any problems in using Logitech Webcam Software (LWS) and found no problems, it works fine if it is just manually launched via the Start Menu shortcut that gets created when LWS is installed. Note, however, that the target for the installed shortcut is: C:\Program Files (x86)\Common Files\LogiShrd\LWSPlugins\LWS\Applets\HelpMain\launchershortcut.exe -- so the LWS.exe is being launched by some 'intermediary' process, I have no idea why. (This 'suite' of stuff that Logitech produced is a veritable spaghetti junction of processes interacting with each other and doing God knows what.) In any case, on my own system I created my own shortcut to launch LWS.exe manually via a batch file and in the process have the CameraHelperShell.exe create its LWSDebugOut.txt in a ramdisk which on my system has drive label W:\. As far as I am concerned it can create and write it in there to its heart's content. (I still do keep the read-only, zero-bytes sized LWSDebugOut.txt file in %TEMP% -- just to be on the safe side.) The batch file is this: title Logitech Webcam Software(TEMP)to Ramdisk mkdir W:\TEMP mkdir W:\TMP set TMP=W:\TMP set TEMP=W:\TEMP start "" "C:\Program Files (x86)\Common Files\LogiShrd\LWSPlugins\LWS\Applets\HelpMain\launchershortcut.exe" exit Cutting a long story short on a lot of experimentation I finally created a batch file to use after I was finished in a session of using LWS. The file is as follows: TITLE Kill Logitech Webcam Processes :: Kill the processes and delete the 'Debug' txt file, assuming you don't want to read it. :: The switch /T means to kill the process tree. The switch /F means to 'force' this kill. TASKKILL /IM LWS.exe /T /F TASKKILL /IM CameraHelperShell.exe /T /F DEL W:\TMP\LWSDebugOut.txt EXIT Why do this? If you just exit LWS by closing the GUI window, as you normally do for most programs, then what happens is that the window closes but LWS.exe is still left in the background as a running process. So simplest solution after closing the window manually as you normally would is to run the above batch and that kills the processes that I know of connected to Logitech that might be persistent in continuing running after you close the window. Your tale of the virus and the files it created is quite apt. I read a couple of accounts of people not realising that the LWSDebugOut.txt was an issue until it had grown to multi-gigabytes in size. "Argh! What's eating up my disk space!" Thanks a bunch Logitech! P.S. On a different subject if you are using LWS to try and record videos and find that you can't successfully do that because, like me, you have an old computer that can't handle what LWS is trying to do when recording videos then I would very much recommend giving Open Broadcaster Software (OBS) a go. Using that I was able to record videos without dropping frames, which was happening when trying to use LWS for the same purpose. I did have to tweak the settings of OBS to achieve this and the document General Performance And Encoding Issues solved the issue for me, particularly the section titled "Change your x264 preset". Note that if you try to download OBS it says that the software is for Windows 8.x and above. However, official word in OBS forums is that it (currently) should work on Windows 7, it's just that if you use it in Win7 then you can't count on getting support at OBS forums. The version that I have now been successfully using on Win7 is OBS v27.0.1. Please also note that you would still need LWS on your system and that should be installed before installing OBS. You need LWS to control the camera. And you use OBS to control the recording, with a lot more functions than LWS offers. But, at least on my system, if I launch OBS it automatically launches the LWS 'Controller' for me so that I can make camera adjustments prior to creating a recording. Hope all this helps someone sometime.
  2. System Details: OS: Windows 7 Pro. SP1 x64 Webcam: Logitech HD Pro Webcam C920 Webcam Operating Software: Logitech Webcam Software 2.51.828.0 Thanks very much for the response Tripredacus. I looked in Device Manager as you said and couldn't find anything that looked remotely connected to this issue. Now, with some thought, I've decided to abandon trying to fix that problem. I have come across several accounts on the internet that describe the same errors being reported in the debug text but no one actually had a clue as to how to fix it. Also, when the webcam is connect to the system I works just fine so I'm not going to bang my head on that any further, I thought it might be easy to fix -- but thanks again for the response. However, I came across a more pressing issue -- the constantly growing LWSDebugOut.txt file -- that did need a solution and I managed to work out how to deal with that which I will detail below. Thanks too to jumper. Yes I found that 'read-only' advice on the web. As a quick fix for a problem it does work. However, I discovered the source of the problem and I'm going to describe it below and how to more comprehensively deal with it as I couldn't find anything on the web that actually did advise how to deal with the issue short of the read-only solution. So to deal with the growing LWSDebugOut.txt file problem. If in the LWS GUI window you untick (i.e disable) the setting Preferences > Logitech Webcam Software Settings > General (tab) > Auto-launch webcam controller then on boot into the system the process CameraHelperShell.exe does not get auto-launched on system bootup and so can't write to the log file. (It is the CameraHelperShell.exe that is writing into the LWSDebugOut.txt file.) This is true if the camera is not plugged in. It is also true if the camera is plugged in. With the option Preferences > Logitech Webcam Software Settings > General (tab) > Auto-launch webcam controller enabled (i.e. ticked) if you boot into the system and the webcam is plugged into a USB port then the CameraHelperShell.exe will write into the LWSDebugOut.txt file once then will stop doing so unless an issue develops with the webcam. However, if you unplug the webcam (and CameraHelperShell.exe is still a running process) then CameraHelperShell.exe will see that as an issue and start appending data into the LWSDebugOut.txt file. If this option is left ticked (i.e. enabled) then if you boot into the system and the webcam is not plugged into a USB port then the CameraHelperShell.exe will start writing appended data into the LWSDebugOut.txt, and that text file will just grow and grow. So the best general advice is to untick the option Preferences > Logitech Webcam Software Settings > General (tab) > Auto-launch webcam controller and that way you won't run into problems if you have the webcam unplugged during bootup. However, it should be noted that clearly CameraHelperShell.exe has an issue with an unplugged webcam -- it considers this a fault and starts appending data into the debug text file. And that (glaring bug if you ask me) is where the fun and games start if you are using LWS GUI window, finish using it, and unplug the webcam from the USB port. What happens in that scenario is that on exit from the LWS GUI window the CameraHelperShell.exe does not get terminated, it keeps running in the background and, probably unawares to the average user, keeps appending data into the LWSDebugOut.txt file. On my system this was being done at a rate at which 1KB of data was added to the LWSDebugOut.txt file every 3 seconds! There are two solutions to this (and there is no reason why your couldn't apply both solutions on your system). The quick way to deal with this issue is to open Windows Task Manager using the keyboard combination Ctrl+Shift+Esc. Click on the 'Processes' (tab) and look for the process CameraHelperShell.exe If it exists click on it to highlight it then click the 'End Process' button. Now confirm that you do want to end the process. That will stop the CameraHelperShell.exe from writing into the debug text file. Now go into your %TEMP% folder and open the file LWSDebugOut.txt in Notepad, delete all the text in there and then save the file. Doing this should give you a LWSDebugOut.txt that is zero bytes in size. The reason for doing this is that it is an easy value to remember -- if it ever changes then you will know that somehow the CameraHelperShell.ex has been writing into the file. Now in Windows Explorer right click on the file and select 'Properties'. In the file Properties look for the item Attributes: 'Read-only', put a tick in that box then click the OK button. You have set that file to read-only, so now the CameraHelperShell.exe can't write into it. There a couple of 'problems' with using this method. Problem 1 -- the most critical one. If you ever delete the LWSDebugOut.txt file, and that might be because you're using system (so-called) cleaning software, or you might inadvertently do that manually, then CameraHelperShell.exe will create a new LWSDebugOut.txt file and start writing into that, as the new file is not set to read-only. Problem 2 - CameraHelperShell.exe is still running on your system and is still, at least trying, to write into the LWSDebugOut.txt file every second. The other 'fix' you can do is make sure you terminate the CameraHelperShell.exe process after using the LWS GUI window to take a picture or do a recording. This can be done by using a batch file. So create a batch file with this content: TITLE Kill Logitech Webcam Processes :: Kill the process :: The switch /T means to kill the process tree. The switch /F means to 'force' this kill. TASKKILL /IM CameraHelperShell.exe /T /F EXIT (If you're not sure how to create a batch file search for instructions on the internet.) Once you have the batch file created store it somewhere you will keep it and once you have done that create a shortcut to the batch file. Now put a copy of the shortcut into you Start Menu. So now when you use LWS do the following. (1) Once your work is finished exit LWS GUI window as you would normally do. (2) Having done that, then use the shortcut in your Start Menu to launch the batch file and the batch will terminate the CameraHelperShell.exe process and you will no longer have the problem of the CameraHelperShell.exe trying to write to the debug text file. So now you have two ways of stopping that LWSDebugOut.txt file from growing and growing if you as an idiotic user ever decide to have the temerity of unplugging your Logitech webcam if you're not using it. P.S. Couldn't find some of this information on the internet so thought to post it here and it might help others with this LWSDebugOut.txt file problem. Thanks again for the help already given. P.P.S. I am using LWS because my computer can't deal with the current software Logitech offers for this webcam Logitech Capture. If I try to use Logitech Capture on my system then it proceeds to try and fry my CPU -- hence I can't use that software. My brief experiments with trying to use Capture just left me thinking that Logitech have produced a good webcam but the controlling software they produce is abysmally poor.
  3. System Details: OS: Windows 7 Pro. SP1 x64 Webcam: Logitech HD Pro Webcam C920 Webcam Operating Software: Logitech Webcam Software 2.51.828.0 I very recently bought the above webcam and installed it and its operating software to my system. I seems to work fine except that it generates a debug file called LWSDebugOut.txt. I only discovered that file by accident and found it to be huge. It seems that the webcam software writes into the file every time the webcam is launched but it just appends the information into the file every time the webcam software is launched. It always seems to record the same errors. The errors it is warning about are as follows: CMicrophoneDeviceManager::GetDeviceIndexInWave() - failed to find match for device path - device ID: : 1 .\MicrophoneDeviceManager.cpp Line: 117 \\?\hdaudio#func_01&ven_10ec&dev_0887&subsys_1458a002&rev_1003#4&395a8c5b&0&0201#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\rtlineinwave .\MicrophoneDeviceManager.cpp Line: 118 CMicrophoneDeviceManager::GetDeviceFriendlyName() - lWaveDeviceIndex == -1 .\MicrophoneDeviceManager.cpp Line: 503 CDeviceInfoMap::GetPnPId() - failed m_DeviceInfoMap.Lookup - device ID: : 0 .\DeviceInfoMap.cpp Line: 406 CDeviceInfoMap::GetPnPId() - failed m_DeviceInfoMap.Lookup - device ID: : 0 .\DeviceInfoMap.cpp Line: 406 CDeviceInfoMap::GetPnPId() - failed m_DeviceInfoMap.Lookup - device ID: : 0 .\DeviceInfoMap.cpp Line: 406 I don't have the expertise to know what the problem is with this, lots of 'fails'. Could someone please explain to me what this means and also how to fix it (if it is fixable).
  4. Yes, I think there is something going on. Previously I did have the Scotland flag, but not now, some change must have been made at the site. Ah, well. Thanks for trying -- sounds like a problem without a solution.
  5. Thanks for the response jaclaz. As you recommended I installed Samsung Magician and set the OP via that. I still think Magician is an ill-implemented piece of software. For Disk 1, the disk with the odd number of primary partitions, it is definitely an MBR drive; I was just experimenting with Linux Mint to see if I wanted to move over to it again. I had used Mint for about a year a fair while back and in the end decided it wasn't a very user friendly OS so I went back to Win7. My experiment with Mint this time lasted two days and I decided it still wasn't user friendly enough. Ah, well. Disk 1 is now reformatted and I'll just use it as an emergency back up for my day to day Win7 system.
  6. Tripredacus. From the url you advised here is the flag of Scotland: You are right that my IP will resolve to a UK domain. There are reasons for that concerning a long history of politics (which I sincerely hope will be sorted out some day soon).
  7. For a good while I had for my profile selected the flag for Scotland and this was used to show correctly below my avatar. Today I logged in to MSFN and see that my flag had changed to UK flag i.e. to the Union Jack. I went to my profile and saw that somehow I had been assigned to living in the UK - I don't know who did this, I certainly didn't. So I used the drop-down and changed that back to I live in Scotland and saved the changes. However, still the forums seem to think that I'm in the UK. Could someone please look into this and correct things. Many thanks.
  8. Hi Folks, I have two Samsung SSDs. I do not (any longer) install Samsung's "Samsung Magician" software as it is a heap of rubbish. So to set Over Provisioning (OP) I just set up partitions and format the drives with Windows 7 or, from a boot disk, I use Gparted. So I ended up with two disks which Windows 'Disk Management' shows as below: As you can see Disk 0 partitioned by Windows has unformatted Free Space at the end of the drive, which I am hoping will be automatically used by the drive as OP space. Disk 1 was partitioned by Gparted and has 'Unallocated' space at the end of the drive, which I am hoping will be used by the drive as OP. So my question is which of these two 'forms' of free space, 'Free Space' or 'Unallocated', is correct? Can the drives use either of these forms as OP or is only one of them correct? P.S. I do know that, according to Windows, Disk 1 has 5 Primary partitions. However, that drive has ext4 formatted partitions and I'm guessing that Windows is just doing a dud job in identifying what the partitions are.
  9. I suppose the best way forward would be to stop this from happening in the first place, but I don't know how. Does the problem only occur with one particular window associated to one particular program? Or does it occur with all windows. I run Win7 and have no problems at all of the type you describe. However, you might find Sizer useful for quickly positioning and sizing a window. At least it would give you an easy to use (once you got it setup) workaround for now. With Sizer you can control the size of the window and the window's position on the screen relative to the coordinates of the monitor screen. Once you have that set-up you can assign a keyboard shortcut to (then) automatically size and position the window when you press the keyboard shortcut combination - the window you want to do this to has to be the active window when you press the shortcut combination. You might find that helpful for just now.
  10. Yeah. Forgot to mention 7+ Taskbar Tweaker. That's a double-plus-good (in the genuine sense) for Win7 and it can be 'installed' as a portable. Also worth a mention is Sizer. Kind of a niche program but use it for a couple of months and you won't end up deleting it as 'useless'. Again, can be 'installed' as portable.
  11. If you do go over to Win7 then at some point you're going to have deal with the 'issue' on what you're going to do about Microsoft Updates. At minimum you're going to have to find out what updates are absolutely essential to giving you a useable system. On that account I would recommend reading the following thread in its entirety: Update Win 7, or Not ? With respect to the books you mention I have no knowledge of them. However, when I first came to Win7 I got a hold of Windows 7 Annoyances by David A. Karp. I found it very informative and useful during install and configuring lots of aspects of Win7. In particular it had the information I needed to get Win7 to install onto a single partition (no hidden 'system reserved' partition necessary). To buy that book new is expensive but you should be able to pick up a second-hand copy very cheaply.
  12. Definitely download, install and configure Classic Shell. This will give you a good experience of Windows Explorer on 7 that has strong similarities to WinXP. I'm on Windows 7 myself but only because Classic Shell makes Explorer and the Start Menu tolerable for me - if Classic Shell wasn't available then I would think I'd just go over to Linux Mint. In point of comparison I have to say that I do find Win7 to be a pretty good system and am overall well pleased with it.
  13. @Karol I'm going out on a limb but the difficulty you are experiencing might be down to not having SHA256 patches installed to your Windows 7. Read through these two threads (you'll have to read through them in their entirety to get a proper handle on what they are about) and see if the information in them is relevant to your problem. https://msfn.org/board/topic/177590-update-win-7-or-not/ https://msfn.org/board/topic/178186-looking-for-info-about-the-upcoming-standalone-sha-2-patch-for-win7/ At one point in time I had issues with not being able to install some software to Win7 (just as you are) but installing the SHA2 patches cured the issue. That said, I wasn't getting the same error messages you are getting, but reading your posts here I end up thinking that maybe the problems are related to these SHA2 issues and associated changes Microsoft introduced to software installing (third-party software and Microsoft Updates) because of them.
  14. @Karol Have you updated your Win7 install at all using Microsoft Updates?
  15. I am on Windows 7 and will sticking with it. I would guess that will fine for me for many years. However, you should read the entire thread posted here for some things to consider: Update Win 7, or Not ? and act on the information there.

  • Create New...