Is there a way to handle catch exception in MSI install wizard? - exception

I am facing some odd situation that when I select/deselect the features in the feature customization wizard, it sometimes crashes the window. It does not give any clue at all. It also not happens consistently.
Do you have any idea or faced such kind of issue? I am able to even trace the root cause using install log.

You may be able to get closer to isolating the problem if you turn on the Debug policy. Do this by setting HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer's Debug value to (dword) 7 in as described on the Windows Installer team blog. You will then need to use a tool like DebugView to view the extra output that Windows Installer will generate. Note you may have to restart the "msiserver" service for the policy to take effect. Best luck making sense of what it shows; often it's just a lot of SQL query dumps.

You can sometimes grab MSI exceptions from out of the event log, but they won't always tell you much.
Instead what you can do is turn on logging of the MSI, this can be done either via the registry, or via the command line. To find out about the registry option, visit this MS Support article. To do it from the command line you can use the same switches, but they obviously will only last for that one install. This is a snapshot as gathered from msiexec:
Logging Options
/l[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] <LogFile>
i - Status messages
w - Nonfatal warnings
e - All error messages
a - Start up of actions
r - Action-specific records
u - User requests
c - Initial UI parameters
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
v - Verbose output
x - Extra debugging information
+ - Append to existing log file
! - Flush each line to the log
* - Log all information, except for v and x options
/log <LogFile>
Equivalent of /l* <LogFile>
To take advantage of these options, use msiexec directly:
msiexec.exe [path to your msi] /l [your options]

Related

400-unknown or invalid client_id for forge-bim360-data.connector.dashboard

I have tried to implement - https://github.com/Autodesk-Forge/forge-bim360-data.connector.dashboard
I have updated this part - npm install set FORGE_CLIENT_ID=<<YOUR CLIENT ID FROM DEVELOPER PORTAL>> set FORGE_CLIENT_SECRET=<<YOUR CLIENT SECRET>> set FORGE_CALLBACK_URL=<<your callback url of Forge e.g. http://localhost:3000/oauth/callback>> set DC_CALLBACK_URL=<<"your ngrok address here: e.g. http://abcd1234.ngrok.io/job/callback">>
I am getting the error that 400-Unknown or invalid client_id
Firstly, I rarely used Windows OS now. I simply copied the guideline of setting environment variables from other samples, while most time, I tried with debug mode (setting environment variables in launch.json) .
checking the Readme again, I found the wording is:
Windows (use Node.js command line from Start menu)
i.e. it asks to input those commands to command line of Node.js, instead of terminal of VSCode! That is why it always reports the error of client id is not defined because the variables are not set to environment at all.
The correct way is to open the command line of Node.js, and run the commands. This is a screenshot.

Symfony 4 framework session handler error

I'm using symfony 4, What does error stands for ?
Warning: SessionHandler::read(): open(/var/lib/php/sessions/sess_634q91mh896b6aa4jpjvlihmar, O_RDWR) failed: Permission denied (13)
When a user logs into a Symfony application, session information is stored on the web server. By default Symfony uses the native PHP session mechanism, storing session info in a file in /var/lib/php/sessions/ on Linux systems. Your error message is output by PHP and means it got a permissions error creating or re-opening a session file.
The error appears only intermittently because PHP removes old session files randomly about every 1/100th or 1/1000th page load. (On some Linux variants, old session files are removed by a cron job instead.)
https://symfony.com/doc/current/session.html says:
"some session expiration related options may not work as expected if other applications that write to the same directory have short max lifetime settings."
Try to avoid having multiple processes writing to the same sessions directory. I think I got the error message because both an Apache web server and php bin/console server:start were running at the same time. One process may have removed the other process's session file.
See PHP manual and Symfony manual for how to configure writing to separate directories. For example, I changed {Symfony directory}/config/packages/framework.yaml:
# Enables session support. Note that the session will ONLY be started if you read or write from it.
# Remove or comment this section to explicitly disable session support.
session:
# handler_id: ~
cookie_secure: auto
cookie_samesite: lax
handler_id: 'session.handler.native_file'
save_path: '%kernel.project_dir%/var/sessions/%kernel.environment%'
gc_probability: 100 # Run garbage collection always for
gc_divisor: 100 # investigating this problem only.
Another possibility is a problem in your Symfony code can cause the error message. The Symfony documentation says not to call the PHP session functions like session_start() directly since Symfony classes call them. A bug in my code caused an exception which I speculate caused the error message.
Related stack overflow questions: cleanup-php-session-files and how-does-php-know-when-to-delete-a-session
For those familiar with C code, see the PHP interpreter source code line that prints the error here
Hope this helps!
Not related to symfony 4, but you have to fix permissions in your /var/lib/php/sessions/ directory

Application Verifier 6.2 (x64) AVRF: failed to create verifier log file status C0000022

My Windows Store app keeps getting rejected from certification testing and I managed to reproduce a consequent crash when running appverif's LuaPriv-check. I get this output though:
AVRF: failed to create verifier log file \??\C:\Users\xx\AppVerifierLogs\yy.exe.0.dat (status C0000022)
Process Monitor tells me yy.exe got ACCESS DENIED on a CreateFile operation in this folder. I have set full access to all users (the user reported in the log was the same as the owner of the folder). I am running Visual Studio and Application Verifier as Administrator, but this does not seem to apply. What is the correct way of giving user xx full access to this folder on win8? I have attempted to use different log folders for appverify but with no success. Anyone else able to use this tool with Store-apps?
This post describes similar issues. Attempting to run AppVerif –sppath C:\MyLogsLocation as in the suggested workaround gives AVRF: Error: Incorrect image name: <
So does running appverif -enable handles locks -for myapp.exe -sppath c:\MyLogsLocation
It might be a bug in app verifier.
Have a look at these links:
http://social.technet.microsoft.com/Forums/en-US/5ed560c0-76af-401d-8150-8cd1e69d0b8a/why-app-verifier-can-not-create-log-file?forum=windowssdk
http://blogs.msdn.com/b/dougste/archive/2010/01/11/generating-application-verifier-logs-for-web-applications.aspx
0xc000022 is STATUS_ACCESS_DENIED. The process doesn't actually have write permissions, even if it looks like it should. This MSDN blog explains there is a bug in App Verifier so even if you specify -sppath the value won't be honoured unless you first delete the %WINDIR%\system32\config\AppVerifierLogs\ folder.

Executing a system command from mysql

I am trying to execute a shell command from within mysql (from within a procedure or a trigger or the command line for mysql).
I have added lib_mysqludf_sys to the mysql plugins and created the functions that are available with the library. (the library) home page
The library has 5 functions.
sys_set - to set $PATH - this works and stores the $PATH which i can later check.
sys_get - to get the stored value of $PATH - this also works and returns the value that I have stored.
sys_exec - to execute a command in the system and return the exit code.
sys_eval - to execute a command in the system and return the standard output.
lib_mysqludf_sys_info - return the current version of the library - this also works.
I need sys_exec and sys_eval to work correctly.
I think I have found the problem in my search but cannot solve it.
mysql is limited by apparmor and is not granted access to execute system commands by the default apparmor profile. I have tried the commands in the documentation to disable a single profile, disable the framework, putting all profiles except one into enforce mode and putting all profiles in complain mode. Nothing works. the command
sudo apparmor_status
always gives me the same output.
20 profiles are loaded.
20 profiles are in enforce mode.
/opt/extras.ubuntu.com/unity-lens-askubuntu/unity-askubuntu-daemon
/sbin/dhclient
/usr/bin/evince
/usr/bin/evince-previewer
/usr/bin/evince-previewer//launchpad_integration
/usr/bin/evince-previewer//sanitized_helper
/usr/bin/evince-thumbnailer
/usr/bin/evince-thumbnailer//sanitized_helper
/usr/bin/evince//launchpad_integration
/usr/bin/evince//sanitized_helper
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/connman/scripts/dhclient-script
/usr/lib/cups/backend/cups-pdf
/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper
/usr/lib/telepathy/mission-control-5
/usr/lib/telepathy/telepathy-*
/usr/sbin/cupsd
/usr/sbin/mysqld
/usr/sbin/tcpdump
/usr/share/gdm/guest-session/Xsession
0 profiles are in complain mode.
5 processes have profiles defined.
5 processes are in enforce mode.
/sbin/dhclient (2537)
/usr/lib/telepathy/mission-control-5 (2709)
/usr/sbin/cupsd (12245)
/usr/sbin/cupsd (12250)
/usr/sbin/mysqld (12675)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Please tell me how I could disable apparmor or change the profile for mysql so that it has access to executing system commands.
The reason I am doing all this is so that I can execute a system command when somethings happen in the DB (via a DB trigger), if you have suggestion for some other ways in which this can be easily implemented then please mention those too.
Thanks.
managed to get this working. First put apparmor in complain mode for the necessary profiles then used apparmor's interactive tools (aa-genprof/aa-logprof) to configure the profile for mysqld

MySQL driver segfaulting under mod_perl - where to look for issue

I have a webapp that segfaults when the database in restarted and it tries to use the old connections. Running it under gdb --args apache -X leads to the following output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212868928 (LWP 16098)]
0xb7471c20 in mysql_send_query () from /usr/lib/libmysqlclient.so.15
I've checked that the drivers and database are all up to date (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).
Annoyingly I can't reproduce this with a trivial script:
use DBI;
use Test::More tests => 2;
my $dbh = DBI->connect( "dbi:mysql:test", 'root' );
sub test_db {
my ($number) = $dbh->selectrow_array("select 1 ");
return $number;
}
is test_db, 1, "connected to db";
warn "restart db now";
getc;
is test_db, 1, "connected to db";
Which gives the following:
ok 1 - connected to db
restart db now at dbd-mysql-test.pl line 23.
DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17.
not ok 2 - connected to db
# Failed test 'connected to db'
# at dbd-mysql-test.pl line 26.
# got: undef
# expected: '1'
This behaves correctly, telling me why the request failed.
What stumps me is that it is segfaulting, which it shouldn't do. As it only appears to happen when the whole app is running (which uses DBIx::Class) it is hard to reduce it to a test case.
Where should I start to look to debug this? Has anyone else seen this?
UPDATE: further prodding showed that it being under mod_perl was a red herring. Having reduced it to a simple test script I've now posted to the DBI mailing list. Thanks for your answers.
What this probably means is that there's a difference between your mod_perl environment and the one you were testing via your script. Some things to check:
Was your mod_perl compiled with the same version of Perl
Are the #INC's the same for both
Are you using threads in your mod_perl setup? I don't believe DBD::mysql is completely thread-safe.
I've seen this problem, but I'm not sure it had the same cause as yours. Are you by chance using a certain module for sending mails (forgot the name, sorry) from your application? When we had the problem in a project, after days of debugging we found that this mail module was doing strange things with open file descriptors, then forked off another process which called the console tool sendmail, which again did strange things with file descriptors. I guess one of the file descriptors it messed around with was the connection to the database, but I'm still not sure about that. The problem disappeared when we switched to another module for sending mails. Maybe it's worth a look for you too.
If you're getting a segfault, do you have a core file greated? If not, check ulimit -c. If that returns 0, your system won't create core files and you'll have to change that. If you do have a core file, you can use gdb or similar tools to debug it. It's not particularly fun, but it's possible. The start of the command will look something like:
gbd /usr/bin/httpd core
There are plenty of tutorials for debugging core files scattered about the Web.
Update: Just found a reference for ensuring you get core dumps from mod_perl. That should help.
This is a known problem in old DBD::mysql. Upgrade it (4.008 is not up to date).
There's a simple test script attached to https://rt.cpan.org/Public/Bug/Display.html?id=37027
that will trigger this bug.